RBAC基于角色的权限管理--设计篇1.1
2018-01-04 16:18
429 查看
RBAC基于角色的权限管理--设计篇1.1
RBAC基于角色的权限管理--设计篇1.0
https://my.oschina.net/xiaozhutefannao/blog/1600612权限控制
数据权限
场景
有些业务可能会是这样。一个列表(或表格),要求普通用户只能看到自己创建的列表信息,业务部门经理只能看到本部门的所有列表信息。这种权限如何控制?表设计
部门表CREATE TABLE `t_dept` ( `id` int(10) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `name` varchar(255) DEFAULT NULL COMMENT '部门名称', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
工单表(列表信息模拟)
CREATE TABLE `t_gd` ( `id` int(10) NOT NULL AUTO_INCREMENT COMMENT '工单ID', `name` varchar(255) DEFAULT NULL COMMENT '工单名称', `creater` int(10) DEFAULT NULL COMMENT '创建人', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
用户部门关系表(这里为了不破坏之前的表设计,在t_user中添加deptid也可以)
CREATE TABLE `t_user_dept` ( `userid` int(10) NOT NULL COMMENT '用户ID', `deptid` int(10) NOT NULL COMMENT '部门ID', PRIMARY KEY (`userid`,`deptid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
常见处理方式-代码写死
就以我说的简单场景为例。看到自己创建的列表信息无非就是select * from t_gd where creater = xxx
业务部门经理只能看到本部门的所有列表信息无非就是
SELECT t1. NAME FROM t_gd t1, t_user t2, t_user_dept t3 WHERE t1.creater = t2.id AND t2.id = t3.userid AND t3.deptid = '业务部门经理的部门id'
在java代码中,做好if-else判断,也算完成了这个小任务。
用表做关联处理
显而易见,上面的方式有点“硬编码”,你的PM or 小老板表示很不满意,“这给我们的维护带来的巨大的工作量”,“我觉得这不行”,“我觉得你可以不用来了(作者开个玩笑)”那么问题来了,如何解决这个所谓的“硬编码”问题?
数据权限表
CREATE TABLE `t_permission_data` ( `id` int(10) NOT NULL COMMENT '主键ID', `gd_creater` int(10) DEFAULT NULL COMMENT '工单创建人', `gd_creater_deptid` int(10) DEFAULT NULL COMMENT '工单创建人部门id', `roleid` int(10) DEFAULT NULL COMMENT '角色id', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
表说明 : 某个角色可以看到工单下某个用户创建的数据或用户所在部门的数据。
看到自己创建的列表信息无非就是
SELECT t1. NAME FROM t_gd t1 WHERE t1.creater IN ( SELECT t0.gd_creater FROM t_permission_data t0 WHERE roleid = '当前登录用户的角色id' )
业务部门经理只能看到本部门的所有列表信息无非就是
SELECT t1. NAME FROM t_gd t1, t_user t2, t_user_dept t3 WHERE t1.creater = t2.id AND t2.id = t3.userid AND t3.deptid in (SELECT t0.gd_creater_deptid FROM t_permission_data t0 WHERE roleid = '当前登录用户的角色id')
这么做的优点是,未来某个角色想看任何一个用户or任何一个部门的信息都是非常轻松的,当然,需要页面支撑一下修改字段值即可。
升级
以上设计看似解决了硬编码问题,但有个常见的问题。PM OR 小老板会告诉你,“xx,用户需求又变了,工单部分还要添加新的数据权限,这个用户比较强势,搞吧”。遇到这种问题,我们势必还要增加表字段,修改我们的代码,看起来多多少少也有些工作量。怎么办呢?下回见。
(本文章后期优化更新)
相关文章推荐
- RBAC基于角色的权限管理--设计篇1.0
- 基于角色的权限管理数据库设计(RBAC)
- 基于角色的权限管理数据库设计(RBAC)
- RBAC基于角色的权限管理--设计篇1.0
- 基于RBAC模型的通用权限管理系统的设计(数据模型)的扩展
- 基于RBAC模型的通用权限管理系统的设计(数据模型)的扩展
- 1 RBAC(基于角色的权限管理)
- 基于RBAC模型的通用权限管理设计
- rbac(基于角色权限控制)-------权限管理
- 基于角色管理(RBAC)的权限系统
- 基于角色的权限管理(RBAC)介绍-简略清晰版
- 基于RBAC模型的权限管理系统的设计和实现
- 【商业版、提供全部源码】基于RBAC的C#ASP.NET支持多用户的通用权限管理系统高质量源码10月份销售20套【提供操作手册设计文档下载】
- 基于角色实现的权限管理数据库设计
- 基于角色-资源-用户的权限管理设计
- 如何设计数据库表实现完整的RBAC(基于角色权限控制)
- 基于RBAC模型的通用权限管理系统的设计(数据模型)的扩展
- 基于RBAC模型的权限管理系统的设计和实现
- 基于Unity的AOP的符合基于角色的访问控制(RBAC)模型的通用权限设计
- 权限管理之基于RBAC的设计方案