权限控制方案

编程

* 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张表)

(一)表结构

  1. 用户(User)

字段

类型

描述

id

Integer

主键

name

String

用户姓名

...

...

其他

  1. 角色(role)

字段

类型

描述

id

Integer

主键

name

String

角色名称

keyword

String

角色关键字,用于权限控制

description

String

描述

  1. 用户角色中间表(user_role)

字段

类型

描述

user_id

Integer

用户ID

role_id

Integer

角色ID

  1. 权限(permission)

字段

类型

描述

id

Integer

主键

name

String

权限名称

keyword

String

权限关键字,用于权限控制

description

String

描述

  1. 角色权限中间表(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

回到顶部