| 04【若依框架】 权限管理详解（精华） | 您所在的位置：网站首页 › 若依框架和vue的关系 › 04【若依框架】 权限管理详解（精华） |
|
背景
权限管理策略是每个后台管理系统都需要考虑的，我所在的项目组工程比较老旧，所以打算参考若依改造一个新的权限管理系统。 若依的权限管理并不是最完美的，但是属于比较标准的，容易改造。本篇更侧重于设计和概念，具体的代码可以直接阅读源码，不复杂。 RBAC 基于角色的权限管理模型 基于角色，没有角色就没有权限菜单权限+接口调用权限+数据访问权限三部分组成了权限管理的全部。菜单管理决定了用户登录后可以看到那些菜单，接口权限决定了用户可以调用那些接口，数据权限决定了用户调用接口时所能查看的数据范围。 关于用户，角色，菜单，部门的认识 角色管理 角色和菜单关联，决定了一个角色匹配的菜单树角色和数据关联，代表具备该角色用户数据查看关系，有下面几种关系。可以参考《数据范围过滤的动态实现》那篇文章 全部数据权限自定数据权限本部门数据权限本部门及以下数据权限仅本人数据权限 角色权限字符role_key(暂时不知道啥用) 数据权限的基本认识 数据是用户产生的，所谓数据权限即用户对数据的CRUD.用户隶属于部门，上级通常具备下级的CRUD(视情况)一个用户能对那些数据，具备那些权限就是数据权限控制的目标。增删改这三种权限，所有用户一旦具备了就无太大差异。即用户有了相关接口权限即可。查看权限具有范围问题，不同用户即使都有查看数据列表的权限，实际上可以查看的数据范围可能大不相同。一句话概括：数据查看权限即role-depts的一对多关系，一个role能看到那些部门的数据。 部门管理 上级部门常识上具备管理下级部门的权限，这也是数据查看的默认权限。领导可能管理多个部门，即存在兼任的情况。注：不能以兼任本身作为数据的管控，因为可能存在多个业务的情况不同需求对于数据查看权限可能完全不同，这种情况下有两种方法可以应对。 为每一种需求业务创建一套新的角色，可能存在一个用户很多角色的情况,但这个也是标准的用法为角色和权限的关联关系加一个字段，businessType通过业务类型抽取对应业务的权限和菜单。这种方式若依并没实现，所以需要做扩展处理。 菜单管理菜单管理是较为复杂的，从表及里涉及后端前端等很多方面。这里主要从后端的角度看待菜单及接口权限的控制。同时忽略到部分次要的功能。 菜单分类 M 菜单，仅用于分类页面，并无跳转的效果。C 页面，具体的页面点击页面会跳转到前端对应的页面F 按钮功能，页面上的按钮，例如：增，删，改，查，导出，导入等。菜单的沟通点是每个菜单对应了一个接口权限，不同点在于页面控制的通常是查看，按钮通常控制修改删除的权限。但是整体来说控制是统一的。 组件地址component对应前端页面的具体地址，这个需要前端提供 路由path和前端没有天大关联，代表了当前菜单的标识为，可以按照规则拼接成权限标识。 权限标识system:user:query 通常由 M:C:F组成，代表了一个权限最小的标识为，达到了按钮级别，这也是权限可以控制到接口（按钮）的根本。 表面上来说这个只是字符串，前后端都会做字符串的解析，前端用于控制按钮的是否可以点击，后端用于控制接口是否可以调用。 权限控制 后端@PreAuthorize 标注在每个方法上 @PreAuthorize("@ss.hasPermi('system:menu:list')")@ss代表的是PermissionService服务，对每个接口拦截并调用PermissionService的对应方法判断接口调用者的权限 hasPermi 是否有菜单权限hasRole 是否有某个角色其他方式都接近，原理也很简单 拦截所有请求，获取注解的属性对比登录用户的角色和菜单判断当前用户的角色是否符合规则，符合就放行否则拒绝。PreAuthorize 这个是spring security的注解，可以通过AOP自己实现 |
| CopyRight 2018-2019 实验室设备网 版权所有 |