按照计划本暑假进行点名系统的大型更新，其一重头戏就是强化权限体系，加入角色的概念。如何优雅、高效地实现权限认证成了一个棘手的问题。参考网上部分文章，初步计划应用下面的设计。在此整理记录一下。
基本思路
“角色”是权限的最小单位，所有用户必须关联角色，不允许直接赋予权限。一个用户可以关联多个角色，其权限取并集。
每个角色可以包含各种权限。
用“位”表示权限
最简单粗暴的权限记录形式就是列表，例如如下一个用于记录权限的数据表：
[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该如何是好。
权限分组
未完待续。。。
