介绍
今天看了一篇文章说的是权限管理RBAC，这个缩略词感觉很高大上，然后细读之后发现就是我之前在项目中所使用的，差不多一样的套路。
文章地址 RBAC权限模型——项目实战
整理一下之前负责的项目所使用的权限是如何处理的，具体的RBAC的原理可以看上面这篇文章，我这里简单说一下为什么这样处理。
如何设计权限
第一个版本
任何一个项目只要涉及到不同的用户使用就会使用权限控制。这里的权限控制就是指一个用户登录系统之后拥有哪些可以使用的功能，哪些可以查看的数据。常见于一个系统之中，不同的角色的人登录系统之后，所看到的菜单是否一样，每个菜单打开之后是否都具有增删查改的权限。
根据以上就出涉及到的几个相关的对象
- 用户
- 菜单
- 操作(按钮,链接,api的调用,数据的查看)
很容易设计出数据库的表结构
这是最简单的设计，用户和菜单多对多 则需要一个中间表，总共四张表搞定。适合小系统。
这里解释一下permission表
其中 name表示权限的名称，field表示受控制的元素name,如果type是1,表示控制按钮的操作，前端页面会根据用户的权限是否显示该按钮，同时根据url字段后台也会控制相应的请求是否有权限。
如果type为0，则表示后端查询的数据要过滤掉field中所设置的字段。同时前端也要控制表格的列显示。这样前后端都可以控制住权限
所有的数据不设置则表示默认有权限。
这样设计的目的能够从前端到后端统一控制
前端草图
但是，随着用户后期的添加，每增加一个用户，就需要制定该用户的一系列菜单。简单也带来了相应的问题。所有需要角色表来处理
第二个版本 RBAC0
当添加了角色表后，用户和角色多对多，角色和菜单多对多，然后角色和权限多对多，因此会多出三张张中间表
这个版本就已经达到了RBAC0的结构
第三个版本 RBAC1
在第二版中，基本上可以满足一般系统的需求，但是当角色过多的时候，会出现一个问题就是，用户赋予多个角色的时候，多个角色之间的权限如何管理。比如同时赋予分管领导的角色和公司领导的角色，那么公司领导的角色是大于分管领导的。拥有的权限完全包括分管领导的权限，
这个时候引入了RBAC1,
角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构
这个版本在第二版的基础上改进新增了一张角色分级表，有了这个表，当用户拥有了多个角色之后，安装level的大小分级，处理拥有level越大的权限越大。
在随着系统的扩大之后，可以引入用户组的概念，但是我觉得没有这个必要，角色已经充当了用户组的概念，没必要多弄几张表搞这么复杂。
RBAC2
主要是指在授权阶段
RBAC2，它是RBAC的约束模型，RBAC2也是建立的RBAC0的基础之上的，在RBAC0基础上假如了约束的概念，主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。
SSD是用户和角色的指派阶段加入的，主要是对用户和角色有如下约束:
a、互斥角色：同一个用户在两个互斥角色中只能选择一个
b、基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的
c、先决条件约束：用户想要获得高级角色，首先必须拥有低级角色
DSD是会话和角色之间的约束，可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。
RBAC3
RBAC3，它是RBAC1与RBAC2合集，所以RBAC3是既有角色分层又有约束的一种模型
