案例演示：ToB领域的权限体系实战
背景
之前在另一篇文章里介绍了权限体系的基础概念如RBCA和ACL，网友反馈说不够深入，需要来点见真章的东东，最好是能够看完后，就可以直接拿到工作中投入使用的。联想到工作中遇到的几个都属于ToB领域里，但面向不同业务方向和类型的实际项目，拿来具体讨论一下，如何为平台设计一个比较通用的权限系统。
原型图
我这里用的是xiaopiu，在线绘图。不用额外安装程序。如果专业点的，一般会用axure，有一定的学习门槛。
从这张原型图里，可以看到这是一个体现了权限体系核心功能的简单系统。
- 当王经理登录的时候，不仅能管理系统概况，也能管理具体的实用功能也就是围栏和视频系统。
- 当巡逻员小李和巡逻员小明登录的时候，他们只能管理围栏和视频系统。
- 通过账户和角色的组合，就能够实现上面的要求
实现的原理是什么呐？首先来了解下资源的概念
背后的事儿
什么是资源
如果没有【账户】和【角色】，这就变成了一个最纯粹的功能系统了。这个系统由系统概览和实用功能两个一级菜单，以及下层的各个细分功能组成。
第一步需要用标识，来标记这些功能。通俗的，可以将这些功能命名为资源，后台数据库中就是通过资源ID来识别某一个具体的功能的。
页面上的每个元素都要有对应的资源ID，这是为了在前端展示的时候，能够做到让不同用户登录后，有的用户可以查看，有的可以编辑，有的可以删除。
所以第二步，需要定义对各个资源ID能够进行的操作，也就是资源和操作之间会产生一个映射关系。
资源和操作
操作的含义，可以理解为CRUD(创建Create/读取Read/更新Upate/删除Delete)四种类型。一般实际实现过程中，为了不这么麻烦，可以将这四种操作简化为全有或者全无。用映射关系来表示就是
resourceId -> CRUD
实际实现的效果就是，当用户能够看到这个资源，那他就可以操作这个资源。如果真的遇到了有特定的需求，就是对于同一个资源，这一种类型的用户必须有而且只能有查看的权限，同时必须没有编辑的权限，那么就需要将这个映射关系打散为如下格式
resourceId -> R
resourceId -> CUD
接下来，准备工作都做好了。铛铛铛，将进入重头戏，账户和角色。
角色
从业务流程上来讲，是先有角色，再有账户。所以需要先创建一个角色。
王经理是一个账户，他有一个叫做“经理”的角色。系统中新增一个角色的时候，一般至少有3个字段，分别是角色的名称（必填），角色拥有的资源的权限（必填），对于该角色的描述（可选）。对于各项的要求如下：
- 角色的名称不允许重复，如果有多个同样名称的角色，被赋予的权限还不一样，系统就乱套了。
- 对应的资源权限。也就是上面提到的resourceId+CRUD的组合。当然支持多选。也就是同一个角色，可以拥有对多个资源的权限
根据上述描述，在系统中创建两个角色
- 经理角色。具有对资源【系统概览】和【实用功能】【围栏】【视频】的权限。这里要特别提一下，虽然将实用功能和围栏分成两个资源提了，但是实际操作时，当选择了围栏功能时，由于它是实用功能的子节点，默认直接将实用功能的权限也给这个角色就可以了，既简单又不会造成更复杂的情况
- 巡逻员角色。具有对【实用功能】【围栏】【视频】的权限
账户
万事俱备，只欠东风。最后一步就是新建3个帐户。账户新建的时候，需要填写的字段，除了账户名称（当然账户名称也是不允许的重复的）和本身这个系统要求的一些信息（例如照片，手机号，电话号码等）以外，就只需要一个字段【角色】了。
这里的角色字段的取值，来自于上一小节里提到的【角色】。一个账户，可以绑定多个角色。不同的账户，也可以绑定同一个角色。
为了让王经理，小李，小明能够正常服务于自己的岗位，实际上就是：
- 新建一个账户，王经理，绑定的是之前创建好的 经理角色。
- 新建一个账户，小李，绑定的之前创建好的 巡逻员角色
- 新建一个账户，小明，绑定的之前创建好的 巡逻员角色
然后这三个人，用自己的帐号密码登录就可以了
总结
在一个真实的系统中，进行权限操作步骤是：
- 第一步定义自己系统的资源权限映射关系，权限是由资源+操作组成的
- 第二步创建角色，这个过程会将角色和对应的资源权限绑定
- 第三步创建帐号，这个过程会将角色和帐号进行绑定
另外，映射关系为
- 资源和操作：多对多
- 角色和权限：多对多
- 帐号和角色：多对多
本文作者 @花生草 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
