权限系统的设计

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

基本思路

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

用“位”表示权限

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

[Table:permission]

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

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

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

[Table:user]

判断权限

如果我们知道用户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该如何是好。

权限分组

未完待续。

参考文章

• 用户权限的数据库设计