权限系统设计
权限管理是公司数据安全的重要保证，针对不同的岗位，不同的级别看到的数据是不一样的，操作数据的限制也是不一样的。
如何让各个岗位的人在系统上各司其职，就是权限管理要解决的问题。
1. 权限设计
业务分类上来讲权限可以分为数据查看权限，数据修改权限等。
对应到系统设计中有页面权限、菜单权限、按钮权限等。菜单也分一级菜单、二级菜单甚至三级菜单，菜单对应的页面里又有很多按钮。
我们在设计的时候最好把权限设计成树形结构，这样在申请权限的时候就可以一目了然的看到菜单的结构，需要哪些权限就非常的明了了。
2.权限模型的演进
RBAC全称为基于角色的访问控制模型（Role-based access control），在该模型中，通过让权限与角色关联来实现授权，给用户分配一系列的角色来让注册用户得到这些角色对应的权限。
1. RBAC0/基本模型
RBAC0是最基本的模型，未做特殊要求和扩展，在该模型中，一个用户可以同时拥有多个角色，每个角色可以拥有多个权限。
表设计：
2. RBAC1/角色继承的RBAC模型
由于具有公司的岗位具有上下级关系，且上级拥有下级的所有权限，所以不同的角色之间存在着重叠的权限，如：
员工：员工的权限
主管：员工的权限、主管的权限
老板：员工的权限、主管的权限、老板的权限
存在的弊端是：每当增加一条员工的权限，都需要同时绑定给【员工】、【主管】和【老板】。倘若将【老板】漏了，那么就会出现【员工有权限，而老板没权限】的情况了。
设计思路：上层角色默认拥有下层角色的所有权限。
表设计：需要在刚才的基础上增加角色继承表，来记录角色之间的继承关系，包括两个字段角色ID和父角色ID
3. RBAC2/带约束的RBAC模型
带约束的RBAC模型又称RBAC2模型。基于RBAC0模型的基础上，进行了角色的访问控制。此模型中常用以下限制：
互斥角色：同一个用户在两个互斥角色中只能选择一个。
基数约束：一个用户拥有的角色是有限的，一个角色拥有的权限也是有限的。
先决条件约束：用户想要获得上层角色，首先必须拥有下层角色。
运行时互斥 ：允许一个用户具有两个角色，一次鉴权只能使用一个角色。
3. 用户划分
1 用户组（组织）
如果用户数量比较庞大，可以加入用户组模式。需要给用户分组，每个用户组内有多个用户，可以给用户加角色外，也可以给用户组加角色。最终用户拥有的所有权限 = 用户个人拥有的权限+该用户所在用户组拥有的权限。
优势：
- 实现权限分配的自动化： 和组织关系打通之后，按照组织来分配角色，如果有新入职的用户，被划分在某个组织下面之后，会自动获取该组织下所有的权限，无需人工分配。又比如有用户调岗，只需要把组织关系调整就可以了，权限会跟着组织关系自动调整。
- 控制数据权限： 把角色关联到组织，组织里的成员只能看到本组织下的数据，比如市场推广和大客定制，市场推广针对的是零散的客户，大可定制针对的是有一定体量的客户，相互的数据虽然在一个平台，但是只能看自己组织下的数据。
表设计：
4. 实战演练
业务分类上来讲权限可以分为数据查看权限，数据修改权限等。
我们目前是基于RBAC0， 最基本的模型，未做特殊要求和扩展，在该模型中，一个用户可以同时拥有多个角色，每个角色可以拥有多个权限。
1. 表设计：
基础表：
用户 User：id, name
角色 Role: id, name, code
权限模块 Acl_Module：name, parent_id, level, code
权限ACl : id, name, acl_module_id, parent_id, url, type(按钮，请求地址)
关系表：
- 用户-角色关系表
- 角色权限关系表
2. 后端逻辑
- 新建权限点，菜单或者按钮（url是请求地址）
- 创建角色，设置角色名称， 角色读写权限等级（增/删/改/查）中的组合。给这个权限配置新建的权限点以及对应的人
（增删改查，分别对应2，3，5，7 这样的话，数据库只需要存一位去记录，当然存0101这种也行）
- 在权限拦截器增加校验
- 获取当前登录用户可以访问的权限列表
- 将权限列表和当前请求做比较，需满足以下两个条件，即可放行，否则提示没有权限
- 请求URL在当前权限URL列表里
- 当前访问的method也在权限URL列表里（这里需要后端使用restful请求，即增删改查对应 POST，DELETE， PUT，GET， 或者后端带标识过来）
3. 前端逻辑
- 前端在用户登录后，就在localstory里存储了，调用当前user的权限列表的结果，只有用户退出登录后，才会更新
目前没有考虑角色继承和互斥，权限委托