说明：之前写过一篇博客，介绍如何搭建一个基于角色的权限验证框架

• 搭建一个基于角色的权限验证框架

本文介绍在非常受欢迎的开源框架——芋道中是如何实现 RBAC 的，芋道的部署参考下面这篇文章：

• 芋道微服务代码部署

介绍

一般来说，系统内用户权限分以下两类，RBAC（基于角色的权限验证）对应的是第一类。

• 菜单权限：用户能看到那些菜单，与用户所拥有的角色挂钩；

• 数据权限：用户能看到那些数据，与用户所处的部门挂钩；

（1）数据库表设计

五张表，三张实体表，两张映射表。通过给角色赋予菜单，用户赋予角色来控制用户所能访问的菜单，RBAC 的基础操作

（2）接口设计

用户赋予角色，角色赋予权限接口

实际上就是往两张映射表里写数据

（3）接口校验

用户仅能看到所拥有角色权限内的菜单，需要前端和后端共同实现，前端仅展示当前用户能看到的菜单（包括按钮），后端需要给每个接口设置权限标识，没有权限的用户访问接口会被拦截。

看芋道是怎么实现的？下面这个接口返回了当前用户权限信息，包括了用户信息、角色信息和菜单权限信息

前端通过返回的数据，展示对应的菜单和按钮。另外，在管理员或者拥有修改某角色权限的用户修改角色的菜单权限时，保证对应角色用户的权限能实时生效，前端可以控制调用该接口的时机。

也就是什么时候调用该接口？是登录时调用一次，还是进入菜单，展示内容前先调用查一遍？这决定了角色权限生效的时效。

在后端，需要给每个按钮对应访问的接口设置权限标识，并在用户访问时判断当前用户是否拥有该权限。如下，

点进去，查看实现，也还是通过当前用户 ID + 权限标识判断

hasAnyPermissionsCache 是用户 ID 对应权限的 Map 集合，使用了本地缓存，过期时间 1 分钟

查看数据来源，也就是用用户 ID 去查了数据库，获取当前用户的所有角色

查出角色后再查角色所拥有的权限，挨个与当前传入的权限标识比较，看在不在这里面

（4）设置当前用户

这里，在校验 token 的拦截器中，将当前用户信息设置到上线文中

这里放了 用户 ID 和用户 Type，如果你需要用到用户的其他信息，如 用户名、性别等，也可以在这里加

扩展

这里演示新增一个接口，加入到 RBAC 校验体系中。

（1）新增按钮

在系统设置中，新增一个按钮，这里可以选按钮所在的上级菜单，及该按钮在哪个页面里，再设置一个权限标识，这个标识前端用于判断是否展示按钮，后端用于校验用户是否拥有访问权限，所以前后端要约定好。

（2）开发接口

接着，后端程序员就去开发自己的接口，开发完后，在接口上加上这行校验注解

（3）测试

创建一个角色，将该权限不赋予给这个角色

再将这个角色赋予给某个用户

设置完，前端应该不会给这个用户展示这个按钮，使用 apifox 用该用户的 token 调用该接口，提示没有操作权限

总结

本文介绍了在芋道框架中 RBAC 实现的细节