04【若依框架】 权限管理详解（精华）

背景

权限管理策略是每个后台管理系统都需要考虑的，我所在的项目组工程比较老旧，所以打算参考若依改造一个新的权限管理系统。
若依的权限管理并不是最完美的，但是属于比较标准的，容易改造。本篇更侧重于设计和概念，具体的代码可以直接阅读源码，不复杂。

RBAC 基于角色的权限管理模型

1. 基于角色，没有角色就没有权限
2. 菜单权限+接口调用权限+数据访问权限三部分组成了权限管理的全部。菜单管理决定了用户登录后可以看到那些菜单，接口权限决定了用户可以调用那些接口，数据权限决定了用户调用接口时所能查看的数据范围。

关于用户，角色，菜单，部门的认识

角色管理

1. 角色和菜单关联，决定了一个角色匹配的菜单树
2. 角色和数据关联，代表具备该角色用户数据查看关系，有下面几种关系。可以参考《数据范围过滤的动态实现》那篇文章

• 全部数据权限
• 自定数据权限
• 本部门数据权限
• 本部门及以下数据权限
• 仅本人数据权限

3. 角色权限字符role_key(暂时不知道啥用)

数据权限的基本认识

1. 数据是用户产生的，所谓数据权限即用户对数据的CRUD.
2. 用户隶属于部门，上级通常具备下级的CRUD(视情况)
3. 一个用户能对那些数据，具备那些权限就是数据权限控制的目标。
4. 增删改这三种权限，所有用户一旦具备了就无太大差异。即用户有了相关接口权限即可。
5. 查看权限具有范围问题，不同用户即使都有查看数据列表的权限，实际上可以查看的数据范围可能大不相同。

一句话概括：数据查看权限即role-depts的一对多关系，一个role能看到那些部门的数据。

部门管理

1. 上级部门常识上具备管理下级部门的权限，这也是数据查看的默认权限。
2. 领导可能管理多个部门，即存在兼任的情况。注：不能以兼任本身作为数据的管控，因为可能存在多个业务的情况
3. 不同需求对于数据查看权限可能完全不同，这种情况下有两种方法可以应对。
   • 为每一种需求业务创建一套新的角色，可能存在一个用户很多角色的情况,但这个也是标准的用法
   • 为角色和权限的关联关系加一个字段，businessType通过业务类型抽取对应业务的权限和菜单。这种方式若依并没实现，所以需要做扩展处理。

菜单管理

菜单管理是较为复杂的，从表及里涉及后端前端等很多方面。这里主要从后端的角度看待菜单及接口权限的控制。同时忽略到部分次要的功能。

菜单分类

• M 菜单，仅用于分类页面，并无跳转的效果。
• C 页面，具体的页面点击页面会跳转到前端对应的页面
• F 按钮功能，页面上的按钮，例如：增，删，改，查，导出，导入等。

菜单的沟通点是每个菜单对应了一个接口权限，不同点在于页面控制的通常是查看，按钮通常控制修改删除的权限。但是整体来说控制是统一的。

组件地址component

对应前端页面的具体地址，这个需要前端提供

路由path

和前端没有天大关联，代表了当前菜单的标识为，可以按照规则拼接成权限标识。

权限标识

system:user:query

通常由 M:C:F组成，代表了一个权限最小的标识为，达到了按钮级别，这也是权限可以控制到接口（按钮）的根本。

表面上来说这个只是字符串，前后端都会做字符串的解析，前端用于控制按钮的是否可以点击，后端用于控制接口是否可以调用。

权限控制

后端

@PreAuthorize 标注在每个方法上

@PreAuthorize("@ss.hasPermi('system:menu:list')")

@ss代表的是PermissionService服务，对每个接口拦截并调用PermissionService的对应方法判断接口调用者的权限

• hasPermi 是否有菜单权限
• hasRole 是否有某个角色

其他方式都接近，原理也很简单

1. 拦截所有请求，获取注解的属性
2. 对比登录用户的角色和菜单判断当前用户的角色是否符合规则，符合就放行否则拒绝。

PreAuthorize 这个是spring security的注解，可以通过AOP自己实现