权限系统的设计

按照计划本暑假进行点名系统的大型更新,其一重头戏就是强化权限体系,加入角色的概念。如何优雅、高效地实现权限认证成了一个棘手的问题。参考网上部分文章,初步计划应用下面的设计。在此整理记录一下。

基本思路

“角色”是权限的最小单位,所有用户必须关联角色,不允许直接赋予权限。一个用户可以关联多个角色,其权限取并集。
每个角色可以包含各种权限。

用“位”表示权限

最简单粗暴的权限记录形式就是列表,例如如下一个用于记录权限的数据表:

[Table:permission]

Id UserName Permission
0 aaa LEAVE_BROWSE
1 aaa LEAVE_ADD
2 aaa LEAVE_DEL
3 bbb LEAVE_BROWSE

此种记录方法虽简单直观,但冗余数据过多,每一次判断权限都需要查询一遍整个表,性能差,尤其在用户与权限种类较多的时候。
用“位”表示权限的理论基础是超递增序列:1,2,4,8,16……,即:2^n(n>=0)。此数列有这样一个特性:拼出的任意一个和数一定可以由这个序列中的一些数构成,且构成方法唯一。例如:20=16+4且只有16和4可以拼出20.借助这个特性我们可以用来表示权限。

首先建立权限内容与编号的对应关系(可写为常量或xml或其他任意类型):

编号(为2^n) 说明
1 读取请假列表
2 添加请假列表
4 删除请假列表

假设用户aaa同时具有读取与添加请假列表的权限,只需要将他的权值设为1+2=3即可。
如此一来,上述的权限表甚至可以删掉,直接集成在用户表里就够了:

[Table:user]

UserName Permission …OtherFields
aaa 7
bbb 1
…… …… ……

判断权限

如果我们知道用户aaa的权值为3,如何判断他是否具有某一权限呢?
很简单,只需要进行位与运算即可。若结果不为0则表示具有此权限。

例如:
3D=011B;1D=001B;2D=010B;4D=100B
011B & 010B = 010B ≠ 0,则具有添加权限。
011B & 100B = 000B,则不具有删除权限。

增加权限

那么如果在已有权限基础上增加一个权限呢?
只需进行位或即可。

例如:
011B | 100B = 111B = 7D
在读取与添加的基础上增加了删除权限。
同时发现7=1+2+4,与上述超递增序列的定义是一致的

删除权限

当然,有时我们也需要剥夺某人的一些权限。
只要与上按位取反即可。

例如:
111B &~ 010B = 101B = 5D
此时剥夺了添加权限,只剩读取、删除权限了。

范围问题

不难看出,此处的权值是个整数,一般情况下应该会习惯性地用int存储,这样问题就来了,int一般情况下只能表示2^32,如果权限种类大于32该如何是好。

权限分组

未完待续。

参考文章

喜欢就赏个点心钱吧(* "・∀・)ノ――◎