聊一个 GitHub 上开源的 RBAC 权限管理系统,很6!

[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.项目部署

  1. 通过 git 下载源码
  2. 创建数据库 wetech_admin,数据库编码为UTF-8
  3. 依次执行 src/main/resources/schema.sql 和 dsrc/main/resources/data.sql 文件,初始化数据
  4. 修改 application-dev.properties 文件,更新 MySQL 账号和密码
  5. 启动服务,账号密码: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)) {
//生成jwt token
JwtToken token = new JwtToken(req.getHeader(AUTHORIZATION_HEADER));
//委托给Realm进行验证
try {
getSubject(request, response).login(token);
return true;
} catch (Exception e) {
}
}
onLoginFail(response);
return false;
}

/**
* 登录失败时默认返回401状态码
*
* @param response
* @throws IOException
*/
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());
}

//交给AuthenticatingRealm使用CredentialsMatcher进行密码匹配,不设置则使用默认的SimpleCredentialsMatcher
SimpleAuthenticationInfo authenticationInfo = new SimpleAuthenticationInfo(
username, //用户名
credentials, //凭证
getName() //realm name
);
return authenticationInfo;
}
}

认证逻辑松哥刚才已经说过了,就不再赘述。

授权逻辑就是根据用户名查询出用户角色,根据用户角色查询出用户权限,将角色和权限分别赋值给 SimpleAuthorizationInfo 对象即可。

最后在 ShiroConfig 中还有一些常规配置,我就不再多说。

权限的控制主要是在各个接口上添加 @RequiresPermissions 注解实现的。如 PermissionController、RoleController 以及 UserController。

5.小结

整体上来说,这个项目并没有太多难度。还是松哥一开始所说的,RBAC 只是一种权限设计模型,模型本身很好理解,涉及到的技术也都很简单。无论是 Shiro 还是 Spring Security,实现 RBAC 虽然有一些差别,但是用的都是最基本的技术点。

好啦,今天就和小伙伴们聊这么多,感兴趣的小伙伴可以看看哦~如果你有好的 RBAC 项目也可以留言告诉松哥,我抽空解析一波。

喜欢这篇文章吗?扫码关注公众号【江南一点雨】【江南一点雨】专注于 SPRING BOOT+微服务以及前后端分离技术,每天推送原创技术干货,关注后回复 JAVA,领取松哥为你精心准备的 JAVA 干货!

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×