系统架构–权限模块的设计
如何评估一个研发人员技术水平,在大部分的情况下不是看其完成业务代码的好坏,更多的时候还是需要看这个研发人员从零构建一个完整项目的能力,在大公司中这样的机会可能相对较少,大部分的时间里都是对现有项目业务的小修小改,如果不跳出这样的环境,日积月累基本可以说沦为了一个螺丝钉式的业务工程师。相反中小厂能够提供研发人员发挥的空间更大,从某种程度上而言在失去大厂成熟的基建支持环境后,更能考验一个工程师的技术功底。在有过一些实际的项目经验之后,我们可以清晰的认识到,绝大部分的项目由于业务场景的不同,业务模块存在很大的变数,但同时一些模块大部分的系统中都是通用的,比如接下来我们将讨论基于rbac的权限模块,而权限模块又可以划分为三个小的功能模块:用户模块、角色模块、菜单模块。
rbac模型是什么?
rbac全称:Role-Based Access Control(基于角色的权限控制系统),核心在于用户只和角色关联,而角色代表对了权限,是一系列权限的集合。rbac的三要素:
RBAC 模型可以分为:RBAC0、RBAC1、RBAC2、RBAC3 四个阶段,一般公司使用 RBAC0 的模型就可以。另外,RBAC0 相当于底层逻辑,后三者都是在 RBAC0 模型上的拔高。
rbac0
用户和角色、角色和权限多对多关系。简单来说就是一个用户拥有多个角色,一个角色可以被多个用户拥有,这是用户和角色的多对多关系;同样的,角色和权限也是如此。
rbac1
相对于 RBAC0 模型,增加了角色分级的逻辑,类似于树形结构,下一节点继承上一节点的所有权限,如 role1 根节点下有 role1.1 和 role1.2 两个子节点
rbac2
如角色互斥,比较经典的案例是财务系统中出纳不得兼管稽核,那么在赋予财务系统操作人员角色时,同一个操作员不能同时拥有出纳和稽核两个角色。如角色数量限制,例如:一个角色专门为公司 CEO 创建的,最后发现公司有 10 个人拥有 CEO 角色,一个公司有 10 个 CEO?这就是对角色数量的限制,它指的是有多少用户能拥有这个角色。RBAC2 模型主要是为了增加角色赋予的限制条件,这也符合权限系统的目标:权责明确,系统使用安全、保密。