基于角色的权限设计方案

资源概念
资源就是想要的到的最终物质,我们可以给每一个资源定义一个权限，也可以给某一类资源定义一个权限

权限概念
权限是对资源的一种保护访问.用户要访问A资源前提是用户必须有A资源的访问权限.

 

角色概念
实事上我们不会直接把权限赋予给用户，而是通过角色来赋予给用户,因为用户拥有某一种权限是因为用户扮演着某一种角色。在权限划分上，我们会把权限赋予给某一个角色，而不是赋予给个人。这样带来的好处是如果公司换了管理角色，那么只要再聘用一个人来做管理者就可以了，而不会出现因为权限在个人手里导致权限被带走的情况具体表：

分组概念
只有角色是不够的，B公司发现A有财务问题成立了一个财务调查小组,然后我们赋予了这个小组财务调查员的角色(注意是赋予小组这个角色).这样这个小组的所有人员都有财务调查的资格。而不需要给小组的每个人都赋予这个角色，分组概念也适合部门，因为任何一个部门在公司里或者社会上都在扮演着一个泛的角色。

用户对资源的访问控制
判断用户有没有访问资源的权限就看这个用户有没有访问这个资源的权限,也就是说分组，分部门,分角色最终是以权限来实现对资源的访问控制

 

 

实体功能对象：

 用户(User)，角色(Role)，权限(Right)
 用户与角色的关系(User&Role)

 权限与角色的关系(Right&Role)

 

 

 

对应的数据库表结构：

用户信息表，角色表，权限功能表

角色用户表

角色功能表

 
权限设计模式
用户+组+角色+权限

用户+组+权限

用户+角色+权限

用户+权限

 

用户权限系统的核心由三部分构成：创造权限、分配权限和使用权限。

以“整数”来表示权限值，如添加、浏览、删除和修改，分别用1、2、4、8这几个整数来代替，不过，各人的做法有所不同

用2的n次幂组成权限值的集合，如1、2、4、8、16...，某用户的权限值为其子集中的整数之和，如 7=1+2+4，5=1+4。如果要从数据库检索包含某几种权限的用户，则先把这几种权限值相加，假设和为k，然后select * from table where 1 and 用户权限值 = 'k'；如果要判断某用户有哪些权限，则取出其权限值k，分别用k&1,K&2,K&4,k&16...,如果为真，则 表示有值等于“&”右边整数的权限，例如，如果k&4为真，则此用户有权限表中值等于4的权限

 

用质数2、3、5、7、11...组成权限集合，某用户的权限为其子集中各整数的乘积，如 210 = 2*3*5*7,我觉得这种方法很有趣，难点在于如何分解质因数；但我有些不认同原作者的提法，他认为权限之间可能存在包含关系，如某用户有删除权限，则 其一定有浏览权限，要不然就没法删除，事实确实是这样，不过我认为这样太复杂了，容易出错，我觉得权限最好是“原子”的，互不干扰，也就是说某用户有删除 权限而没浏览权限则其无法进行删除操作，因为他看不到东西，解决这个矛盾的关键是在给用户赋权时，把浏览权限也赋给他