权限系统设计目的：
对不同的人访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。
权限模型
RBAC 模型, 基于角色的访问控制（Role-Based Access Control)
角色：
用户的权限通过角色去分配，从而避免用户过多，逐一设置权限麻烦，角色起到了桥梁的作用。
同时，为一个用户分配多个角色，这个用户就拥有多个角色下的多个权限
好处：
1.实现了用户与权限的解耦
2.提高了权限配置的效率，只需要建好对应的角色就行
权限：
即用户可以访问的资源。权限分为三类：
1. 页面权限
用户登录系统可以看到的页面, 由菜单来控制, 菜单包括一级菜单和二级菜单, 只要用户有一级和二级菜单的权限, 那么用户就可以访问页面
2. 操作权限
即页面的功能按钮，包括查看, 新增, 修改, 删除, 审核等，用户点击删除按钮时，后台会校验用户角色下的所有权限是否包含该删除权限。如果是, 就可以进行下一步操作, 反之提示无权限。
有的系统要求 “可见即可操作”, 意思是如果页面上能够看到操作按钮, 那么用户就可以操作, 要实现此需求, 这里就需要前端来配合, 前端开发把用户的权限信息缓存, 在页面判断用户是否包含此权限, 如果有, 就显示该按钮, 如果没有, 就隐藏该按钮。
某种程度上提升了用户体验, 但是在实际场景可自行选择是否需要这样做
3. 数据权限
数据权限就是用户在同一页面看到的数据是不同的，比如财务部只能看到其部门下的用户数据，采购部只看采购部的数据。
在一些大型的公司，全国有很多城市和分公司，比如杭州用户登录系统只能看到杭州的数据，上海用户只能看到上海的数据，解决方案一般是把数据和具体的组织架构关联起来。
举个例子, 在给用户授权的时候, 用户选择某个角色同时绑定组织如财务部或者合肥分公司, 那么该用户就有了该角色下财务部或合肥分公司下的的数据权限。
以上是 RBAC 的核心设计及模型分析, 此模型也叫做 RBAC0, 而基于核心概念之上, RBAC 还提供了扩展模式。包括 RBAC1,RBAC2,RBAC3 模型。下面介绍这三种类型
RBAC1
此模型引入了角色继承 (Hierarchical Role) 概念，即角色具有上下级的关系，角色间的继承关系可分为一般继承关系和受限继承关系。
一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。
而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。
用户——部门——角色——权限
水平越权处理
用户——角色——权限
业务要求：
组织化（上下级组织）：
- 市里面的人员能查看到所有镇和村里面的人员信息（数据范围：全部）
- 镇下面能看到该镇下面所有村的人员信息（数据范围：自定义）
个人化（组织内的上下级）
- 一个组织内，领导能查看工作人员的信息
- 工作人员只能查看自己的信息
水平（跨团队）：
- 镇A能获取到镇B下方的信息
权限设计：
我们可以根据业务要求，将权限设置成两个部分。第一处就是全局数据规则，也就是组织架构对应数据规则；第二处是在用户选择角色的时候，可以配置个性化数据规则。
