权限=功能+数据

1.点明题意

我们来梳理一下用户在系统中看到数据的过程：

  1. 用户需要进入系统，这需要后台管理员给用户分配账号(后台系统是没有注册功能的)
  2. 用户进入系统能看到哪些菜单导航，需要后台给配置
  3. 通过菜单进入到具体的页面，在页面内能访问多少数据量也是有访问限制的
  4. 看到数据了，能对数据做多少操作也是有操作限制的

在上面的过程中，除了第一步的分配账号是由管理员操作的，剩下的三步都和用户所拥有的权限相关。通过具体操作对象的不同，上面三步可以分为两类：

  • 功能：对功能的限制也称功能权限，主要是对访问区域以及对应操作的管理，如能访问的仓库、页面以及页面操作按钮。
  • 数据：对数据的限制也称数据权限，主要是对数据资源的访问控制，如保险箱和页面显示数据。

功能权限

功能权限指的是用户具体能访问哪些菜单，以及对菜单页面中的哪些按钮有操作权限。把多个菜单和对应的功能按钮组织到一起就行程了一个权限列表，具体的组织方式如下图：

image.png
对于用户，如何获取这些权限呢？

方案一（ACL）访问控制列表

通过直接将用户和权限列表绑定在一起，实现的权限管理
image.png

  • 优点：可以为每个用户个性化的设置访问权限。
  • 缺点：当用户数量多，并且拥有相同职能的用户较多时，修改一次权限，就需要耗费很大力气。如销售部有很多的销售专员，因为他们的职位相同，所有获得的操作权限相同，但后期添加或者删除一个访问权限，那么需要给所有人相同职位的人都操作一遍，管理员估计得累死。所以这种设计方案在开发中使用的频率很低。

方案二：RBAC(Role-Based Access Control)，基于角色的访问控制

通过先创建一个角色，然后将权限列表在绑定在这个角色上，之后再将角色和绑定到用户身上，用户就可以获得这个角色的所有权限。
image.png

  • 优点：首先多人可以公用一个角色；再者如果需要对权限进行调整，只需要调整对应角色的权限即可，也就是只需要一次操作，非常易于操作和管理。
  • 缺点：上面优点也是一个缺点，因为权限的操作是按角色来完成的，所以每次修改含有相同角色的用户都会被影响。

如对于同一职位的职员，正常来说大家的权限都是一样的，但是也会有特殊情况发生，比如给其中一个添加或减少部分权限，这个时候就没有办法了。对于这种情况，在现有的设计功能上也是有办法解决的。
通常的方案就是在给角色绑定权限时，先采用权限最小化原则，能少给就少给，然后再做一个角色绑定多余的权限，再把这个角色也绑定给职员，这个时候两个角色的权限就合并到一起了，也就是用户和角色之间是一对多的关系。
image.png
对于RBAC还有几个扩展模型：

  • 第一种：在角色上加入了上下级关系，上级可以继承下级的权限
  • 第二种：在角色之间加入了多个约束关系，如角色互斥、用户基数限制等

原型展示：角色列表页和角色授权页~
image.png
image.png

数据权限

对于数据权限的管理比较复杂，这个主要还是有具体的业务来决定的，下面我们就看几种常见的数据场景以及解决方案。

上下级的数据权限

企业中通常都有销售部，销售部下又分各个大区，大区下又划分小组。对于销售人员来说，他们的薪资是和业绩挂钩的，所以没有人会把自己的客户资源让你别人的，这就导致数据处理上，销售专员通常只能看自己的(自愿共享的就不再这里讨论)，而对于销售主管则能看到手下所有的销售专员的客户资料，同理，大区经理，和销售总监也都能看到自己手下所有人的客户资源。
在这种场景下的数据，很明显是能看出，这是根据企业的组织架构，根据职员的职位高低来控制数据的访问权限。所以它通常的解决方案是和组织架构相关联的，具体逻辑如下：

  1. 在给职员分配账号的时候，设置好对应的部门和职位
  2. 当用户获取数据时，根据自己当前的部门和职位，获取到所有下属的职员信息
  3. 将属于这些下属职员的所有客户信息显示出来，这个数据控制就完成了

分区块的数据访问

分区块的典型案列就是电商企业员工对多个仓库的访问问题，我们假设有一个大的电商平台，它在全国有多个仓库，如北京仓、上海仓、西安仓、甘肃仓。对于各个仓库的职员来说，通常他们只有当前仓库的数据访问权限，而对于总公司的买手、技术等人员来说，他们平时要巡检查看各个仓库数据，所以需要有全部仓库的数据。而仓库的组织架构和买手、技术所属部门并不存在上下级关系。
在这种场景下的数据，它就是按照分区块的方式来划分。要解决这个问题其实也很简单，就是上面讲的【用户-角色-权限列表】，只是这里的权限列表内容不再是菜单和操作按钮，而是各个仓库。

数据访问

数据共享的场景是很常见的，像我们经常使用的协同文档软件，里面都会有将内容共享给个人或者共享给某个组的功能。

分状态的数据访问

分状态的数据控制，这种场景比较少见，一般出现在流程比较长的业务中。如金融借贷系统中，比如一个用户想要去借贷平台上贷款，假设他们的流程如下图：
image.png
通常要完成整个业务流程，需要多个部门相互配合的，由于整个业务涉及了许多客户隐私信息，所以各个部门的职员一般只允许看到对应步骤的数据，如审查组通常只能看到状态为【待审核】的信息，风控组只能看到【待评估】的信息，财务组只能看到【待放贷】的信息。
基于这种场景，有两种解决方案：

  1. 首先在代码里面配置好部门和职位对应的访问状态码(也就是写死在代码里)，当用户访问数据时，根据部门和职位获得对应状态码，再进行数据过滤。优点就是开发比较快写几行逻辑判断就行了，缺点就是如果想给部分人(如公司领导)设置个性化的访问状态码，就很难做到了。
  2. 还是参考【用户-角色-权限列表】的方式，将权限列表里的数据更换成业务状态码，访问数据时，先根据用户设置的角色获取分配的状态码，再根据状态码获取数据。优点是代码开发完后，任意的个性化都可以手动维护并快速配置。缺点就是开发量稍微大一点。

上面两种方式其实内部逻辑是一样的，都是先根据用户的部门和职位先获取状态码再获取数据，但是可操作性和扩展性缺完全不一样。
下图为用户绑定权限的原型
image.png