SpringBoot＋Vue前后端分离，使用SpringSecurity完美处理权限问题（二）

当前后端分离时，权限问题的处理也和我们传统的处理方式有一点差异。笔者前几天刚好在负责一个项目的权限管理模块，现在权限管理模块已经做完了，我想通过5-6篇文章，来介绍一下项目中遇到的问题以及我的解决方案，希望这个系列能够给小伙伴一些帮助。本系列文章并不是手把手的教程，主要介绍了核心思路并讲解了核心代码，完整的代码小伙伴们可以在GitHub上star并clone下来研究。另外，原本计划把项目跑起来放到网上供小伙伴们查看，但是之前买服务器为了省钱，内存只有512M，两个应用跑不起来(已经有一个V部落开源项目在运行)，因此小伙伴们只能将就看一下下面的截图了，GitHub上有部署教程，部署到本地也可以查看完整效果。

项目地址：https://github.com/lenve/vhr

上篇文章我们对项目做了一个整体的介绍，从本文开始，我们就来实现我们的权限管理模块。由于前后端分离，因此我们先来完成后台接口，完成之后，可以先用POSTMAN或者RESTClient等工具进行测试，测试成功之后，我们再来着手开发前端。

本文是本系列的第二篇，建议先阅读前面的文章有助于更好的理解本文：

创建SpringBoot项目

在IDEA中创建SpringBoot项目，创建完成之后，添加如下依赖：

这些都是常规的依赖，有SpringBoot、SpringSecurity、Druid数据库连接池，还有数据库驱动。

然后在application.properties中配置数据库，如下：

OK，至此，我们的工程就创建好了。

创建Hr和HrService

首先我们需要创建Hr类，即我们的用户类，该类实现了UserDetails接口，该类的属性如下：

如果小伙伴对属性的含义有疑问，可以参考1.权限数据库设计.

UserDetails接口默认有几个方法需要实现，这几个方法中，除了isEnabled返回了正常的enabled之外，其他的方法我都统一返回true，因为我这里的业务逻辑并不涉及到账户的锁定、密码的过期等等，只有账户是否被禁用，因此只处理了isEnabled方法，这一块小伙伴可以根据自己的实际情况来调整。另外，UserDetails中还有一个方法叫做getAuthorities，该方法用来获取当前用户所具有的角色，但是小伙伴也看到了，我的Hr中有一个roles属性用来描述当前用户的角色，因此我的getAuthorities方法的实现如下：

即直接从roles中获取当前用户所具有的角色，构造SimpleGrantedAuthority然后返回即可。

创建好Hr之后，接下来我们需要创建HrService，用来执行登录等操作，HrService需要实现UserDetailsService接口，如下：

这里最主要是实现了UserDetailsService接口中的loadUserByUsername方法，在执行登录的过程中，这个方法将根据用户名去查找用户，如果用户不存在，则抛出UsernameNotFoundException异常，否则直接将查到的Hr返回。HrMapper用来执行数据库的查询操作，这个不在本系列的介绍范围内，所有涉及到数据库的操作都将只介绍方法的作用。

自定义FilterInvocationSecurityMetadataSource

FilterInvocationSecurityMetadataSource有一个默认的实现类DefaultFilterInvocationSecurityMetadataSource，该类的主要功能就是通过当前的请求地址，获取该地址需要的用户角色，我们照猫画虎，自己也定义一个FilterInvocationSecurityMetadataSource，如下：

关于自定义这个类，我说如下几点：

1.一开始注入了MenuService，MenuService的作用是用来查询数据库中url pattern和role的对应关系，查询结果是一个List集合，集合中是Menu类，Menu类有两个核心属性，一个是url pattern，即匹配规则(比如)，还有一个是List,即这种规则的路径需要哪些角色才能访问。

2.我们可以从getAttributes(Object o)方法的参数o中提取出当前的请求url，然后将这个请求url和数据库中查询出来的所有url pattern一一对照，看符合哪一个url pattern，然后就获取到该url pattern所对应的角色，当然这个角色可能有多个，所以遍历角色，最后利用SecurityConfig.createList方法来创建一个角色集合。

3.第二步的操作中，涉及到一个优先级问题，比如我的地址是,这个地址既能被匹配，也能被匹配，这就要求我们从数据库查询的时候对数据进行排序，将类型的url pattern放在集合的前面去比较。

4.如果getAttributes(Object o)方法返回null的话，意味着当前这个请求不需要任何角色就能访问，甚至不需要登录。但是在我的整个业务中，并不存在这样的请求，我这里的要求是，所有未匹配到的路径，都是认证(登录)后可访问，因此我在这里返回一个的角色，这种角色在我的角色数据库中并不存在，因此我将在下一步的角色比对过程中特殊处理这种角色。

5.如果地址是/login_p，这个是登录页，不需要任何角色即可访问，直接返回null。

6.getAttributes(Object o)方法返回的集合最终会来到AccessDecisionManager类中，接下来我们再来看AccessDecisionManager类。

自定义AccessDecisionManager

自定义UrlAccessDecisionManager类实现AccessDecisionManager接口，如下：

关于这个类，我说如下几点：

1.decide方法接收三个参数，其中第一个参数中保存了当前登录用户的角色信息，第三个参数则是UrlFilterInvocationSecurityMetadataSource中的getAttributes方法传来的，表示当前请求需要的角色（可能有多个）。

2.如果当前请求需要的权限为则表示登录即可访问，和角色没有关系，此时我需要判断authentication是不是AnonymousAuthenticationToken的一个实例，如果是，则表示当前用户没有登录，没有登录就抛一个BadCredentialsException异常，登录了就直接返回，则这个请求将被成功执行。

3.遍历collection，同时查看当前用户的角色列表中是否具备需要的权限，如果具备就直接返回，否则就抛异常。

4.这里涉及到一个all和any的问题：假设当前用户具备角色A、角色B，当前请求需要角色B、角色C，那么是要当前用户要包含所有请求角色才算授权成功还是只要包含一个就算授权成功？我这里采用了第二种方案，即只要包含一个即可。小伙伴可根据自己的实际情况调整decide方法中的逻辑。

自定义AccessDeniedHandler

通过自定义AccessDeniedHandler我们可以自定义403响应的内容，如下：

配置WebSecurityConfig

最后在webSecurityConfig中完成简单的配置即可，如下：

关于这个配置，我说如下几点：

1.在configure(HttpSecurity http)方法中，通过withObjectPostProcessor将刚刚创建的UrlFilterInvocationSecurityMetadataSource和UrlAccessDecisionManager注入进来。到时候，请求都会经过刚才的过滤器（除了configure(WebSecurity web)方法忽略的请求）。

2.successHandler中配置登录成功时返回的JSON，登录成功时返回当前用户的信息。

3.failureHandler表示登录失败，登录失败的原因可能有多种，我们根据不同的异常输出不同的错误提示即可。

OK，这些操作都完成之后，我们可以通过POSTMAN或者RESTClient来发起一个登录请求，看到如下结果则表示登录成功:

关注公众号，可以及时接收到最新文章: