1272 字
约 4 分钟
20
RBAC 权限模型入门:让系统权限管理更加灵活
RBAC 权限模型入门:让系统权限管理更加灵活
在一个真实项目中,不同用户拥有的操作权限通常是不一样的。
例如一个后台管理系统:
普通员工:
查看订单
查看商品
管理员:
新增用户
删除用户
修改商品
查看数据
如果直接在代码中写:
if(userId == 1){
// 管理员权限
}
随着系统越来越复杂,这种方式会变得难以维护。
因此,企业系统通常会采用一种更加通用的权限设计:
RBAC 权限模型。
一、什么是 RBAC?
RBAC(Role-Based Access Control),即:
基于角色的访问控制模型。
它的核心思想:
用户通过角色拥有权限,而不是直接绑定权限。
关系如下:
用户(User)
↓
角色(Role)
↓
权限(Permission)
例如:
张三
↓
管理员角色
↓
用户管理权限
商品管理权限
订单管理权限
二、为什么不用用户直接绑定权限?
假设系统有:
1000个用户
10个权限
如果直接设计:
用户1 → 权限A
用户1 → 权限B
用户2 → 权限A
用户2 → 权限B
用户3 → 权限A
会产生大量重复。
如果采用 RBAC:
管理员角色
↓
多个权限
1000个用户
↓
绑定管理员角色
只需要管理角色即可。
例如:
新增一个权限:
订单退款
只需要添加到:
管理员角色
所有管理员立即拥有该权限。
三、RBAC 三个核心概念
1. 用户 User
代表系统使用者。
例如:
张三
李四
王五
2. 角色 Role
角色代表一组权限。
例如:
管理员
运营人员
普通用户
角色是用户和权限之间的桥梁。
3. 权限 Permission
表示具体操作。
例如:
user:add
user:delete
article:update
order:view
通常使用:
资源:操作
的形式表示。
例如:
商品:新增
商品:删除
四、RBAC 如何使用?
一个典型后台系统:
数据库设计:
用户表
sys_user
角色表
sys_role
权限表
sys_permission
用户角色关系
sys_user_role
角色权限关系
sys_role_permission
关系:
用户
↓
用户角色表
↓
角色
↓
角色权限表
↓
权限
五、案例:后台管理系统权限设计
假设开发一个商城后台。
有三类用户:
普通员工
角色:
employee
拥有:
商品查看
订单查看
运营人员
角色:
operator
拥有:
商品查看
商品修改
活动管理
管理员
角色:
admin
拥有:
用户管理
商品管理
订单管理
系统设置
权限关系:
admin角色
↓
user:add
user:delete
product:update
order:view
用户登录后:
系统查询:
当前用户角色
↓
角色拥有权限
↓
保存权限信息
↓
访问接口时校验
例如:
访问:
删除用户接口
系统检查:
用户是否拥有:
user:delete
如果有:
允许访问。
没有:
返回:
无权限操作
六、RBAC 常见扩展
实际项目中,RBAC 还会继续扩展。
1. 菜单权限
控制后台菜单显示。
例如:
管理员:
用户管理
商品管理
订单管理
普通用户:
订单管理
2. 按钮权限
控制页面按钮。
例如:
删除按钮:
只有管理员显示
普通员工:
隐藏删除按钮
3. 数据权限
控制数据范围。
例如:
销售人员:
只能查看自己的订单
管理员:
查看全部订单
七、RBAC 与 Sa-Token结合
在项目中:
RBAC 负责:
设计权限关系
Sa-Token 负责:
权限校验执行
流程:
用户登录
↓
查询用户角色
↓
获取权限集合
↓
保存登录状态
↓
访问接口
↓
Sa-Token判断权限
例如:
接口要求:
user:add
用户没有:
返回:
无权限
八、总结
RBAC 的核心思想:
不直接给用户分配权限,而是通过角色管理权限。
它解决了:
- 权限重复配置
- 用户权限难维护
- 系统扩展困难
一个成熟后台系统通常都会采用:
用户(User)
↓
角色(Role)
↓
权限(Permission)
再结合:
- Sa-Token
- Spring Security
- Redis
实现完整的权限认证体系。
在实际项目开发中,RBAC 几乎是后台管理系统权限设计的基础模型。
RBAC 权限模型入门:让系统权限管理更加灵活
https://clxhxhhr.top/posts/2930/ 评论
0 条
还没有评论,先写一条吧。