[TOC]
前两天写了一篇文章，和大家大概聊了聊 RBAC 权限管理系统：
RBAC 理论其实并不难，相信大家看完文章都能明白。但是如何将理论转为实践代码，这还需要一点功力。
大家可能在网上也会见到众多自称 RBAC 的权限管理系统，这些系统有的确实是 RBAC，有的虽然自称 RBAC，其实并不是。
为了帮助小伙伴掌握 RBAC 权限管理模型，松哥经过大量的摸排，找到了一些开源的 RBAC 权限管理系统，我想写几篇文章和大家分析一下这些系统的实现，搞懂了别人的实现逻辑，自己再去做就非常容易了。
今天要和大家介绍的是一个来自 GitHub 上的项目，叫做 wetech-admin。
1.项目介绍
wetech-admin 是基于 Spring Boot 2.0+Mybatis+Vue 的轻量级后台管理系统，适用于中小型项目的管理后台，支持按钮级别的权限控制，系统具有最基本的用户管理、角色管理、权限管理等通用性功能，企业或个人可直接在此基础上进行开发，扩展，添加各自的需求和业务功能!
松哥看了下这个项目，基本上是满足 RBAC0 模型，功能上比较完整，唯一有点遗憾的是，它是用 Shiro 开发的，而不是 Spring Security。
不过这个并不影响我们学习 RBAC，RBAC 作为一种权限模型是语言无关的，无论你用什么语言都可以实现 RBAC，更不用说同一种语言的不同框架了。
只要我们把这个 RBAC 搞懂，用 Spring Security 实现 RBAC 自然也不在话下。其实 Spring Security 实现 RBAC 所需要的技术，在松哥本系列的文章中基本上都已经介绍过了，现在只要大家搞懂了模型，就能很快实现。
我们来看看这个项目的几个效果图：
可以看到，用户列表、角色列表、权限列表，三个菜单涉及到了权限管理中三张表。
2.项目部署
- 通过 git 下载源码
- 创建数据库 wetech_admin，数据库编码为UTF-8
- 依次执行 src/main/resources/schema.sql 和 dsrc/main/resources/data.sql 文件，初始化数据
- 修改 application-dev.properties 文件，更新 MySQL 账号和密码
- 启动服务，账号密码：admin/123456 或者 guest/123456
这是官方给出的部署步骤，松哥再详细说两句。
首先项目下载下来后，包含两个目录：
- wetech-admin-server：服务端项目，但是由于存在一个 parent，所以不能直接打开 wetech-admin-server，从它的上级目录处打开。
- wetech-admin-ui：前端项目，需要首先执行 npm install 安装所需依赖，然后执行 npm run serve 启动前端项目。
没搞过前后端分离的小伙伴注意，需要前后端同时启动才能访问。
松哥在启动前端时遇到一个问题，就是一直报这个错误：
1
| Cannot read property 'range' of null
|
检查过后，发现是 eslint 作怪，我就把 eslint 整个关闭了，然后就清净了。
因为我们这里主要是看 RBAC，前端不做过多涉及，项目跑起来就行。如果大家也遇到这个错误，可以按照松哥的办法试下。
另外需要注意，他这项目用了 Lombok，随意 idea 上需要安装一下 Lombok 插件。
3.数据库分析
这个项目数据库只有三张表：
权限表、角色表以及用户表。
他没有设计关联表，而是将关联数据做成了一个字段。
比如角色表中有一个 permission_ids 字段，表示该角色对应的权限：
用户表中有一个 role_ids 字段，表示用户对应的角色：
这样设计的好处很明显，就是查询的时候非常方便，不用做一对多查询，SQL 好写并且执行效率高。
缺点就是数据更新不太方便，不过一般来说，权限系统数据更新频率较低，大部分都是查询，所以我觉得这样设计也能接受。
我们来看下这里的权限表：
type 表示资源的类型，分为两种：菜单和按钮。
其中 1 表示菜单，2 表示按钮。如果是菜单，则需要有一个动态路由字符串，也就是 config 字段。该字段返回到前端之后，前端就会动态加载出对应的页面（这点和松哥 vhr （https://github.com/lenve/vhr）是一致的）。
角色表和用户表都比较简单，我就不再多说。
4.代码分析
普通的 CURD 代码我就不说了，和权限管理相关的代码在 tech.wetech.admin.shiro 包里边。登录在 LoginController 里边。
先来说这个登录，具体的操作是在 tech.wetech.admin.service.impl.UserServiceImpl#login 方法中：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| @Override
public UserTokenDTO login(LoginDTO loginDTO) {
User user = userMapper.selectByUsername(loginDTO.getUsername());
if (user == null) {
throw new BusinessException(CommonResultStatus.LOGIN_ERROR, "用户不存在");
}
if (!passwordHelper.verifyPassword(user, loginDTO.getPassword())) {
throw new BusinessException(CommonResultStatus.LOGIN_ERROR, "密码错误");
}
UserTokenDTO userInfoDTO = new UserTokenDTO();
userInfoDTO.setUsername(user.getUsername());
userInfoDTO.setToken(JwtUtil.sign(user.getUsername(), String.valueOf(System.currentTimeMillis())));
return userInfoDTO;
}
|
这就是纯手工登录，登录成功后，生成一个 jwt 字符串返回给前端，以后前端每次请求，都需要携带上这个 jwt 字符串来。
tech.wetech.admin.shiro.JwtFilter 是专门处理认证请求的过滤器，所有需要认证的请求，都会经过该过滤器。这个过滤器所做的事情，就是从所有的请求头中提取出 Access-Token（就是登录成功后返回的那个 jwt 令牌），然后从令牌中解析出用户名，调用 JwtRealm 完成校验。
这是 JwtFilter：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
| @Slf4j
public class JwtFilter extends AccessControlFilter {
protected static final String AUTHORIZATION_HEADER = "Access-Token";
protected boolean isLoginAttempt(ServletRequest request, ServletResponse response) {
HttpServletRequest req = (HttpServletRequest) request;
String authorization = req.getHeader(AUTHORIZATION_HEADER);
return authorization != null;
}
@Override
protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object mappedValue) throws Exception {
return false;
}
@Override
protected boolean onAccessDenied(ServletRequest request, ServletResponse response) throws Exception {
HttpServletRequest req = (HttpServletRequest) request;
if (isLoginAttempt(request, response)) {
JwtToken token = new JwtToken(req.getHeader(AUTHORIZATION_HEADER));
try {
getSubject(request, response).login(token);
return true;
} catch (Exception e) {
}
}
onLoginFail(response);
return false;
}
private void onLoginFail(ServletResponse response) throws IOException {
HttpServletResponse httpResponse = (HttpServletResponse) response;
httpResponse.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
httpResponse.setContentType("application/json;charset=utf-8");
httpResponse.getWriter().write(JSONUtil.toJSONString(Result.failure(CommonResultStatus.LOGIN_ERROR)));
}
}
|
JwtRealm 如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
| @Slf4j
public class JwtRealm extends AuthorizingRealm {
@Autowired
private UserService userService;
@Override
public boolean supports(AuthenticationToken token) {
return token instanceof JwtToken;
}
@Override
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
String username = principals.toString();
SimpleAuthorizationInfo authorizationInfo = new SimpleAuthorizationInfo();
authorizationInfo.setRoles(userService.queryRoles(username));
authorizationInfo.setStringPermissions(userService.queryPermissions(username));
return authorizationInfo;
}
@Override
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
String credentials = (String) token.getCredentials();
String username = null;
try {
boolean verify = JwtUtil.verify(credentials);
if (!verify) {
throw new AuthenticationException("Token校验不正确");
}
username = JwtUtil.getClaim(credentials, JwtUtil.ACCOUNT);
} catch (Exception e) {
log.error("Token校验不正确：", e);
throw new AuthenticationException(e.getMessage());
}
SimpleAuthenticationInfo authenticationInfo = new SimpleAuthenticationInfo(
username,
credentials,
getName()
);
return authenticationInfo;
}
}
|
认证逻辑松哥刚才已经说过了，就不再赘述。
授权逻辑就是根据用户名查询出用户角色，根据用户角色查询出用户权限，将角色和权限分别赋值给 SimpleAuthorizationInfo 对象即可。
最后在 ShiroConfig 中还有一些常规配置，我就不再多说。
权限的控制主要是在各个接口上添加 @RequiresPermissions 注解实现的。如 PermissionController、RoleController 以及 UserController。
5.小结
整体上来说，这个项目并没有太多难度。还是松哥一开始所说的，RBAC 只是一种权限设计模型，模型本身很好理解，涉及到的技术也都很简单。无论是 Shiro 还是 Spring Security，实现 RBAC 虽然有一些差别，但是用的都是最基本的技术点。
好啦，今天就和小伙伴们聊这么多，感兴趣的小伙伴可以看看哦～如果你有好的 RBAC 项目也可以留言告诉松哥，我抽空解析一波。
