一、为什么要自己写一个权限框架
笔者待过的多家公司内部的权限框架,大部分配置菜单/权限的功能都是先在页面上添加好,然后每个菜单/权限的判断又得单独写代码来实现,这样显示十分的麻烦。此时笔者就想着能否利用注解实现一个自动化生成菜单/权限的功能,并且能根据自定义注解判断当前用户是否有某个菜单/权限的操作。而且目前大部分的公司都用上了微服务,如果能实现统一权限管理,岂不是节省了很多时间~
二、数据库简单设计
传统的权限设计五张表:用户表、用户关联角色表、角色表、角色关联资源表、资源表;当然更细的还能带上用户关联资源表,并且有的还带上什么公司域、组织域等等,只有更复杂,没有最复杂。这里就用最简单的来展示。下面附上数据库设计图
- 资源表是这几张表中最重要的,其中笔者设计了applicationKey和systemKey,用于满足多项目,多系统的需求。
- 资源表的菜单key的设计规则是:项目英文缩写+系统资源缩写+具体模块。例如商场项目,会员系统、积分菜单可以设计为:mail.member.Integral。
- 资源表的权限key的设计规则是:项目英文缩写+系统资源缩写+具体模块+具体功能。例如商场项目,会员系统、积分模块、积分列表功能可以设计为:mail.member.Integral.list。
三、注解设计
一般系统里面的权限可以分为菜单权限、按钮权限、数据权限。菜单权限和按钮权限可以通过一套固定的规则生成,数据权限一般都是领导定制化开发,所有这里只涉及菜单权限和按钮权限。
在系统中,某个请求一般可分为无需登录即可操作,登录后即可操作,需要权限才可操作。因此笔者设计了两个注解来满足以上功能。
- NoLogin顾名思义就是无需登录即可操作。
- SourceAuth则是资源权限,其中menuKeys、authKeys设计成多个的原因是在项目中,经常某个接口需要再多个页面中使用,或者某个接口只需要众多权限中的一个即可。authName则是显示在页面上给用户看的中文名称。
四、菜单JSON设计
{
"systemKey": "blog",
"applicationKey": "member",
"menus": [
{
"menuKey": "member",
"menuName": "客户管理",
"path": "#",
"sort": 1,
"childMenu": [
{
"menuKey": "member.member",
"menuName": "客户列表",
"path": "/member/list",
"sort": 1
},
{
"menuKey": "member.tag",
"menuName": "客户标签管理",
"path": "/member/tag",
"sort": 2
},
{
"menuKey": "member.integral",
"menuName": "客户标签管理",
"path": "/member/integral",
"sort": 3
}
]
},
{
"menuKey": "system",
"menuName": "系统管理",
"path": "#",
"sort": 1,
"childMenu": [
{
"menuKey": "system.operateLog",
"menuName": "系统操作日志",
"path": "/system/operateLog",
"sort": 2
}
]
}
]
}
- 其中childMenu可以无限层级写下去。
- 下层级的menuKey是上层级的menuKey加上一个
.
,再加上本身的key