RBAC基於角色的權限管理--設計篇1.1 頂 原

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，用戶需求又變了，工單部分還要添加新的數據權限，這個用戶比較強勢，搞吧”。

遇到這種問題，我們勢必還要增加表字段，修改我們的代碼，看起來多多少少也有些工作量。怎麼辦呢？下回見。

(本文章後期優化更新)