权限控制方案
* permission : 权限
ps : 自我感觉写的还算清楚,比较容易理解,不用框架,手动实现好像也...
一:粗粒度(URL级别权限控制)
- 用户表
(customer)
id name
1
jim
2
tom
- 权限表
(permission)
id url
1
../../xxxQuery
2
../../xxxSave
3
../../xxxUpdate
4
../../xxxDelete
- 中间表
customer_permission
c_id p_id
1
1
1
2
1
3
1
4
2
1
- 可以基于filter实现,当用户访问一个URL地址,查询数据库判断用户当前具有的权限是否包含这个URL,如果包含,允许访问,如果不包含,则权限不足
二:细粒度(方法级别权限控制)
- 用户表
(customer)
id name
1
jim
2
tom
- 权限表
(permission)
id desc
1
xxx_query
2
xxx_save
3
xxx_update
4
xxx_delete
- 中间表
customer_permission
c_id p_id
1
1
1
2
1
3
1
4
2
1
- 看着好像差不多,其实并不是
@Permission("xxx_save")save(){
dao.save();
}
- 我们通过在方法上添加自定义注解,这个注解可以描述权限信息,当我们要访问目标对象的方法时,对目标对象创建代理对象,通过反射拿到权限描述,在代理对象中查询数据库判断其是否具有注解上描述的权限,如果有该访问权限,则访问目标对象的方法,反之则拦截,并提示权限不足
三:权限控制常规模型(5张表)
(一)表结构
- 用户
(User)
字段 类型 描述
id
Integer
主键
name
String
用户姓名
...
...
其他
- 角色
(role)
字段 类型 描述
id
Integer
主键
name
String
角色名称
keyword
String
角色关键字,用于权限控制
description
String
描述
- 用户角色中间表
(user_role)
字段 类型 描述
user_id
Integer
用户ID
role_id
Integer
角色ID
- 权限
(permission)
字段 类型 描述
id
Integer
主键
name
String
权限名称
keyword
String
权限关键字,用于权限控制
description
String
描述
- 角色权限中间表
(role_permission)
字段 类型 描述
role_id
Integer
角色ID
permission_id
Integer
权限ID
(二)简单聊一下角色表
- 我们发现这五张表(三张主表)是以角色为中心分别以多对多的形式关联用户和权限,而不是由用户和权限直接关联,这并不是说用户和权限直接关联不可以,只是为了方便我们对用户进行授权
- 打个比方:陆军上将可以管陆军,空军上将可以管空军,海军上将可以管海军,如果你是陆海空三军上将,是不是什么兵都可以管了呢?
- 也就是说,我们为用户分配角色,为角色分配权限,从而达到为用户分配权限的目的,角色的存在就是为了方便对用户授权也可以理解为,角色就是权限的集合
(三)补充:动态菜单管理
- 在后台管理系统中,我们通常需要进行动态菜单管理,即为不同的用户指定不同的系统菜单
- 菜单表
(menu)
字段 类型 描述
id
Integer
主键
name
String
菜单名称
page
String
访问路径
priority
Integer
优先级
description
String
描述
- 我们仍然不直接和用户关联,那样太累了,我们选择通过角色进行管理(其实就是粗粒度url控制)
- 角色菜单表
(role_menu)
字段 类型 描述
role_id
Integer
角色ID
menu_id
Integer
菜单ID
以上是 权限控制方案 的全部内容, 来源链接: utcz.com/z/510280.html