RBAC基于角色的权限管理--设计篇1.1

RBAC基于角色的权限管理--设计篇1.0

https://my.oschina.net/xiaozhutefannao/blog/1600612

权限控制

数据权限

场景

有些业务可能会是这样。一个列表（或表格），要求普通用户只能看到自己创建的列表信息，业务部门经理只能看到本部门的所有列表信息。这种权限如何控制？

表设计

部门表

1CREATE TABLE `t_dept` (
2  `id` int(10) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
3  `name` varchar(255) DEFAULT NULL COMMENT '部门名称',
4  PRIMARY KEY (`id`)
5) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

工单表（列表信息模拟）

1CREATE TABLE `t_gd` (
2  `id` int(10) NOT NULL AUTO_INCREMENT COMMENT '工单ID',
3  `name` varchar(255) DEFAULT NULL COMMENT '工单名称',
4  `creater` int(10) DEFAULT NULL COMMENT '创建人',
5  PRIMARY KEY (`id`)
6) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

用户部门关系表（这里为了不破坏之前的表设计，在t_user中添加deptid也可以）

1CREATE TABLE `t_user_dept` (
2  `userid` int(10) NOT NULL COMMENT '用户ID',
3  `deptid` int(10) NOT NULL COMMENT '部门ID',
4  PRIMARY KEY (`userid`,`deptid`)
5) ENGINE=InnoDB DEFAULT CHARSET=utf8;

常见处理方式-代码写死

就以我说的简单场景为例。看到自己创建的列表信息无非就是

select * from t_gd where creater = xxx

业务部门经理只能看到本部门的所有列表信息无非就是

1SELECT
2	t1. NAME
3FROM
4	t_gd t1,
5	t_user t2,
6	t_user_dept t3
7WHERE
8	t1.creater = t2.id
9AND t2.id = t3.userid
10AND t3.deptid = '业务部门经理的部门id'

在java代码中，做好if-else判断，也算完成了这个小任务。

用表做关联处理

显而易见，上面的方式有点“硬编码”，你的PM or 小老板表示很不满意，“这给我们的维护带来的巨大的工作量”，“我觉得这不行”，“我觉得你可以不用来了（作者开个玩笑）”

那么问题来了，如何解决这个所谓的“硬编码”问题？

数据权限表

1CREATE TABLE `t_permission_data` (
2  `id` int(10) NOT NULL COMMENT '主键ID',
3  `gd_creater` int(10) DEFAULT NULL COMMENT '工单创建人',
4  `gd_creater_deptid` int(10) DEFAULT NULL COMMENT '工单创建人部门id',
5  `roleid` int(10) DEFAULT NULL COMMENT '角色id',
6  PRIMARY KEY (`id`)
7) ENGINE=InnoDB DEFAULT CHARSET=utf8;

表说明：某个角色可以看到工单下某个用户创建的数据或用户所在部门的数据。

看到自己创建的列表信息无非就是

1SELECT
2	t1. NAME
3FROM
4	t_gd t1
5WHERE
6	t1.creater IN (
7		SELECT
8			t0.gd_creater
9		FROM
10			t_permission_data t0
11		WHERE
12			roleid = '当前登录用户的角色id'
13	)

业务部门经理只能看到本部门的所有列表信息无非就是

1SELECT
2	t1. NAME
3FROM
4	t_gd t1,
5	t_user t2,
6	t_user_dept t3
7WHERE
8	t1.creater = t2.id
9AND t2.id = t3.userid
10AND t3.deptid in (SELECT
11			t0.gd_creater_deptid
12		FROM
13			t_permission_data t0
14		WHERE
15			roleid = '当前登录用户的角色id')

这么做的优点是，未来某个角色想看任何一个用户or任何一个部门的信息都是非常轻松的，当然，需要页面支撑一下修改字段值即可。

升级

以上设计看似解决了硬编码问题，但有个常见的问题。PM OR 小老板会告诉你，“xx，用户需求又变了，工单部分还要添加新的数据权限，这个用户比较强势，搞吧”。

遇到这种问题，我们势必还要增加表字段，修改我们的代码，看起来多多少少也有些工作量。怎么办呢？下回见。

(本文章后期优化更新)

RBAC基于角色的权限管理