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

小鱼儿 2022-12-27 01:23 1811阅读 0赞

## 背景 ##

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

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

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

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

### 角色管理 ###

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

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

1.  角色权限字符role\_key(暂时不知道啥用)

### 数据权限的基本认识 ###

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

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

### 部门管理 ###

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

### 菜单管理 ###

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

####  ####

菜单分类

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

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

#### 组件地址component ####

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

#### 路由path ####

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

#### 权限标识 ####

system:user:query