业务系统除了具体的业务之外,最麻烦的就是对于每个成员权限的控制了。最近收拾东西,忽然飘出一张几个月前,进行权限表设计的思路,我觉得还是比较普适的,所以来总结一下。
权限的控制要么是ACL要么是RBAC,他们具体的介绍看这里。
那么我的设计是RBAC的,既基于角色的访问控制,直接上例子吧。
为了避免没人看,我把特点或者说优点放在前面吧:
1)可以针对不同的实体创建不同的权限限制(实体是指如订单、商品等业务实体)。
2)针对某实体的权力可拓展,针对某实体的权力等级大小也可拓展。
3)支持多角色用户。
4)角色可控制不同的实体。
5)换言之,用户对所有实体都有不同的权限控制。
以下表字段一切从简,维护性字段就不写了。
1、首先我们得有个用户表,上面随便弄一些基本属性,以username为主键
2、其次角色表得有吧,来一发角色表。
3、那么考虑到多角色的情况,角色就不能作为一个字段在user表中,角色和用户的关系表得有吧
4、下面就是跟别的权限设计不太一样的地方了,我实现将可能的操作尽可能穷举,那么就设计成酱紫了的一个表。
简单的介绍一下,我弄了一个表称为实体表(entity),它与角色,权力形成一个关系表,称为角色实体权限表吧(简称REP表)。REP表中穷举了可能有的权力,上面即为新增,读取,更新,删除,分派。我将这些权力分级,例如:
权力等级 | 含义 |
0 | 没有权限 |
10 | 自己可操作 |
30 | 同一个组织可操作 |
50 | 所有可操作 |
如果我录入了一条权限数据为,假设role_id为1是普通员工权限,entity_id为1为订单实体
id | role_id | entity_id | can_add | can_read | can_update | can_del | can_assign |
1 | 1 | 1 | 0 | 50 | 30 | 10 | 0 |
那么这条数据就可以解释成,普通员工权限他对于订单这个实体,没有权限增加订单,可以读取所有订单,可以对跟这个员工同一组织下维护的订单进行更新,可以删除自己创建的订单,并且这个订单他没有权限分派给别人。
针对如果一个用户有多个角色,那么我们取所有角色对应操作的最大权力作为一个标准,在缓存中维护着这个权限数据,就可以进行权限管控了。
这里我的权力值使用的是0、10、30、50,这其中其实留了后门,如果我想插入一个权力值位于自己和同一组织之间,例如这个组织下又新建了多个小组,那么我可以使用15作为权力值,这么做是留着用于权力的扩展。
5、但是,总有操作事先没有考虑到的情况或者一些特殊情况,例如小张在不拥有管理员权限的情况下,拥有管理员的某项权力,我们不可能为了一个人去开一个角色吧,没关系,用一个特殊权限表记录即可。
alias就是上面的can_read,can_update这些字段,level就是10、30、50这些权力值,entity_id则为实体id,现在估计看明白了,RPE表和这个表的合集不就可以满足上面的需求嘛。
当然,如果你想要这个特殊权限也是需要配置的,那你为privilege建张表维护即可。
6、看起来整体是这样的
就我暂时使用的情况来说,除了配置起来比较繁琐,暂时还没有不能满足的地方,主要是他可以精确到比较细的粒度,即方便拓展又容易理解,我觉得还不错,个人感觉挺通用的,适合大部分场景,所以拿上来跟大家分享。
完。