一、前言
设计B端产品，无可避免会涉及权限管理的问题。为什么呢？因为B端产品生来就是带着组织结构属性的，它辅助我们分工、协调和合作。所以我们的产品必须紧紧切合职、责、权这三个主题。
二、简介
权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。
三、需求背景
1、为什么要做权限管理呢？
（1）权利不同可以了解的数据内容不同，保证数据隐私，避免数据泄密。
（2）职责不同所需要页面不同，保证操作效率，避免页面干扰；
（3）技术水平不同可以操作的功能不同，保证系统安全，避免操作风险；
（4）还有其他要素都注定了要独立出一个权限管理模块来规范操作和数据权限。
四、实现方式
1、侠侣权限系统模型设计
依据 RBAC 模型思想， 侠侣权限系统业务模型设计为员工管理和权限管理两部分，员工管理主要指管理员工以及为员工指派角色，权限管理主要指管理菜单、页面、按钮、API 等资源，通过定义最基本的业务功能点作为权限点，实现管理角色对资源主体的请求，构成“用户-角色-权限-资源”的授权模型。
权限系统模型中的一些通用语言：
(1)、员工：角色的载体，权限的实行者
(2)、角色：角色是权限集进一步映射。业务系统可动态管理角色,各业务为方便用户使用可提供给默认角色列表，满足不同的员工权限
(3)、权限点：全局唯一的用来表示某一个功能点对应的权限的状态
(4)、功能点：逻辑上定义的用来描述系统资源的最小基本单位，每一个功能点都对应唯一一个权限点
(5)、功能集(权限集)：即功能点的集合，有一组功能点按照特定格式进行组合
2、权限系统模型的实现
在传统的 RBAC 模型中，通常通过一张关系表来保存角色与权限集的对应关系，实现权限与角色相关联。可以预见的是，随着业务的不断发展会积累下不计其数的功能点，导致关联表的数据极难维护和使用。侠侣权限系统利用进制转换的策略解决了这个问题 ，同时提高了存储效率以及权限判定效率。一个基本类型为 Long 的十进制数字，它也可以看做是由 64 位 0 或 1 组成的二进制。在侠侣系统模型设计中，每一个功能点定义为一个权限点，该权限点由 idx 和 pos 两个属性确保是全局唯一的权限点。idx 表示第几个 Long 型空间，pos 表示 Long 型对应的二进制数中所处的位置，64 位长度即可代表 64 个不同能功能点。当 64 位满时无法再容放更多的功能点，这时 idx 属性会自增，重新申请一个 Long 型空间。如此一个 64 位的 Long 数字，通过 0 或 1 的组合，即可表示最多对 64 个不同的功能点所拥有权限的状态描述。
例如：权限集{1}表示拥有 idx=0, pos=0 对应功能点的权限，权限集{-1,1}表示拥有idx=0,pos∈[0,1,2,..,63]与 idx=1,pos=0 对应功能点的权限。
侠侣权限系统将资源与所代表的功能点的关联关系通过进制的方式管理起来，采用计算机进制的思想，抽象出功能集换算公式来完成资源与二进制之间的映射，以及角色与二进制的映射。
权限集换算公式：
{(idx0,pos0),(idx0,pos1)…(idxN,posM)} => {Long0,Long1…LongN}
侠侣权限系统同样通过进制思想实现“ Who 对 What 进行了 How 的操作”，角色请求某个资源（菜单/API）时，通过权限校验计算公式——进制按位“与”运算操作的思想（见下）得出该角色是否拥有访问资源的权限。采用进制来实现运算，权限判定的效率会变得更加的高效。
例如，一个仓管在点击一个商品库存菜单时，背后的权限校验计算公式，其实是将角色的权限集与资源的权限集进行按位与计算，任意一对序号为 idx 的 Long 算得不为 0，即两集合有公共的功能集，认为该角色拥有对资源访问的权限。
权限校验计算公式：
{Long0,Long1…LongN} & {Long0,Long1…LongM}
3、侠侣权限系统架构
(1)、相关表
(2)、菜单渲染
a、结点定位
按照系统功能的划分，菜单通常以一棵树的形式进行展现。在后台访问时，用户停留的菜单通常是页面，页面有一个全局唯一的属性：URL，往上：可以通过父菜单找到根结点，往下，页面下可能包含一些子菜单——按钮。因此只需要根据当前请求的 URL，即可在后台菜单树中定位到唯一的页面菜单，同时获得该菜单的结点路径以及拥有的按钮。
b、权限计算
我们已经获得了用户的角色权限和完整的菜单树，根据每个菜单结点的权限集，可以计算出当前用户对结点的访问权。根据计算结果，客户端对菜单可以进行区分渲染，比如：用户通过拼 URL 访问一个无权限页面时会提示非法。
(3)、API权限校验
除了菜单渲染外，API是另一种被请求的资源类型。API 校验是除了菜单渲染外另一道权限控制的保障。当API请求转发具体业务时，业务系统首先通过上面的权限校验计算公式对该角色是否具有权限访问这个 API 进行判定，若权限校验通过则执行后面业务逻辑。
具体流程如下图所示
API 权限校验流程可以总结如下：
1、业务方在对应需要权限校验的 API 上标注 @desc 注解， 在节点维护管理添加相关相关的控制器
2、然后扫描相关控制器，将所有API扫描到到节点表,然后在功能管理,给功能选择对应的节点。（标红的这一步，按道理是要在扫描的时候就可完成，但这需要所有开发人员执行严格的注解）
3、在获取到角色权限集和 API 权限集后，基于上面的角色与权限校验逻辑进行权限校验。校验通过，则正式发起 API 请求。校验不过，则提示无权限。
