目标
- 权限：可细化到一次Web请求的控制
- 角色：自定义角色、角色可自由组合权限
- 管理账号：可自由组合角色
整体逻辑概述
1584847921.png
效果图
-
权限：image.png
-
角色：image.png
-
管理账号：image.png
实现难点
-
前后端已分离，怎么实现前端与后端权限的绑定
- 前端通过是否显示页面来实现用户权限的控制
- 后端通过每次Web请求鉴权实现（查询统一不鉴权，但都需要登录）
- 后端通过返回前端能够展示的URL来控制前端权限
-
既然要做到每次Web请求的权限控制，怎么实现最小的代码侵入
- 通过Shiro实现除登录、注册外的其他所有请求的是否已登录的控制
- 通过自定义注解扩展Shiro自身的RequiresPermissions注解，实现方法级别权限控制与记录访问日志
- 在自定义注解上添加其与前端页面地址的关联关系
设计方案
表结构设计
image.png
注意：以上表结构通用字段：id、status、remarks、create_time、update_time
-
menu表：通过树型结构的存储来实现后端页面展示与权限页面配置的一致
- 数据来源：用户根据前端页面顺序配置
-
后端页面
image.png -
权限配置页面（图中的“查看客户”、“删除客户”内容是通过分析注解上内容新增的permission记录）
image.png
-
permission表：存储每个menu下包含的权限控制操作
-
数据来源：通过代码生成。每个需要单独权限分配的Action方法上添加自定义注解，如下图： 其中注解有一个属性operate是为了静态绑定页面的二级菜单，并自定义自身的名称，如下图：image.png，后端权限与前端页面是通过上述MenuEnum.CUSTOMER实现绑定，如下图：image.pngimage.png
- 重要思路：
- 在代码中以枚举自定义二级菜单，枚举的ID与用户配置的二级菜单名称（前端页面名称）一致。便于自动绑定表中的二级菜单
- 在代码中以枚举自定义二级菜单的权限，并作用与具体的Action方法。便于自动生成权限记录
- 在Shiro中扩展新注解的拦截，实现每个带有注解的Action都进行权限校验
-
数据来源：通过代码生成。每个需要单独权限分配的Action方法上添加自定义注解，如下图：
-
role表：存储用户自定义权限组合的角色
-
数据来源：用户根据业务场景自定义配置
image.png
-
