最近在考虑设计比较完整可扩展的权限控制机制，希望能够通过这种机制来集中进行权限控制，并借助AOP将权限控制与功能模块分离。

　　原始的做法来源于操作系统的ACL表，建立一张角色与权限的二维表格，角色与权限相交处的值就表示该角色是否具有该权限（或者用数值、集合代表拥有该权限的“程度”），使用查表的方式已经可以达成AOP控制的前提条件。不过，缺陷在于ACL表的表达能力有限，角色和权限都不具有层次性（无法利用继承性简化权限设定操作的复杂度）。

　　另一个问题是，如果一个用户可以拥有多个角色，那么当多个角色之间的权限设定值不同时应该如何取舍也是一个难题。

　　首先为了改善角色的层次性，将角色建立成树形的数据结构，即在数据库中新增一个parent字段（双亲表示法）指出其父角色，需要注意的是，父角色的权限较低，子角色继承了来自父角色的所有权限，还可以具有自己的权限。因此，处于Root的角色，实际上是整个应用中最低权限的角色（角色的默认权限）。对于这个角色的权限描述，则使用灵活性和语义都很强的JSON数组，JSON对象中的key就是权限的key，value就是权限设定值。

　　在继承性上，也同样遇到该用户具有的不同角色的权限设定可能不同的问题，也还不清楚子角色的权限继承行为具体是怎样的。为了解决这个问题，我们引入一个权限的positive属性，来标识该权限是一个积极的属性还是一个消极的属性，另外，还需要一个属性type来标识该权限是数值型、布尔型还是集合类型（在这里讨论这三种类型的权限）。

• 布尔型非常容易理解，就是“是”或“否”、“能”或“不能”，如果positive，就可以描述是否具备某种权限，否则可以描述是否具有某种限制。
• 数值型用来描述某种程度，例如“自我介绍的最大长度”、“最短发帖时间间隔”等，如果positive，则表示数值越大权限越高，否则数值越小权限越高。
• 集合类型表示一个特定的类别序列，例如“可以上传的文件类型”等，如果positive，则集合表示允许的类型序列，集合越大，允许操作的类别多，权限高，否则集合表示禁止的类型序列，集合越大，允许操作的类别越少，权限低。

　　基于这三种情况，我们首先考虑权限继承的问题，在考察某个角色的权限时，首先从该角色开始在JSON对象中搜索该操作所需的权限，无论找到与否都必须继续查找父角色中对该权限的设置，直至查找到根，这时我们自底向上取得了一系列对于该权限的设置，然后我们需要进行合成，合成根据上面权限的三种类型以及positive的值。

• 布尔型：positive表示对所有这些权限值进行或运算，即一旦出现true则结果为true；否则对这些权限值进行与运算，即一旦出现false则结果为false。
• 数值型：positive表示取所有权限值的最大值；否则取所有权限值的最小值。
• 集合类型：positive表示对所有权限值进行并运算；否则对所有权限值进行交运算。

　　如果一个用于具有多种角色，那么在计算得到每个角色的实际权限后，再根据上述规则合成这些角色的权限值。

　　根据上面的思路，角色已经成为树结构，但是权限还是普通表结构，因此，我们考虑允许权限的分组，将权限同样构造为具有层次的树结构。为了使树有意义，我们需要限定非布尔类型的权限只能出现在权限树的叶子节点上。这样，对于非叶子节点，既表示一种权限设置，又决定了其子权限设定是否有意义。

　　为了使得权限设置更加简单，我们甚至还可以引入三状态变量，表示Full、None或者Partial，加快了权限查找效率，有时也简化了某些权限的设定。

• 相关文章
• 全局相关文章