在今天，数据安全越来越重要，这是底线也是红线，马虎不得。而要保障系统数据的安全，权限就是非常重要的一环。怎么能既保障安全可控，又能尽量地不影响用户使用，是我们必须要权衡的。如果权限体系过于复杂严格，那系统使用体验可能就比较差，而如果过于宽松，数据安全就难以保障。
RBAC权限模型
关于这个权限模型，网络上有很多文章，就不重复了。也在网上看了不少相关文章，根据跟我所想要的还是有差距，或者说关注点可能有些不一样。（在手机码这篇文章的时候，发现是自己的理解有问题。这篇文章记录了自己的理解，也避免了开发走向错误的方向，所以还是那个问题：一个问题在内部讨论的时候存在争议的时候，不要急着下结论，一个人坚持自己意见的时候可能都是有某种合理性的，只是可能可能各自的合理性没有表达清楚或者本身没有梳理清楚，所以多想几个为什么。发现码文章就是个好办法）
用户角色的理解
用户关联角色，角色关联权限，然后角色可以组成树形目录结构，这是最基本的原理。原理上，角色也可以进行多继承，就是一个角色可以有多个上级角色，但是不建议使用，多继承只会让权限过于复杂，写代码的都知道，多继承往往是地狱。所以首先确定的是，我们的角色是单继承的，就是一个角色只会有一个上级角色，当然，一个角色可以有多个下级角色。
例如，我们以学校为例，假设学校有两层，就是学校和班级，学校有校长，班级有班主任，这样看一所学校的角色层级就是一个校长下面有若干个班主任，好像是这样的。但是，在学校层面不止有校长，还有副校长等其他角色的领导，在这个单线模型下，要让副校长等领导也能关联下面的班主任，这颗角色树就很难描述清楚，要描述清楚，就必须是一个多继承的关系，也就是班主任这个角色上面除了校长，还有副校长等角色。
于是，大多数角色体系都会分离出部门和角色两类（没错，部门其实就是角色的一种类型，或者叫用户组）。部门很明显，就是树形结构的，很清晰的单继承模型。于是，很多人的权限体系就变成部门下绑定角色，而角色又绑定权限，这看着很好理解。
说到这里，必须得说一下自己之前关于这点上思考的弯路。
关于部门与角色理解的弯路
之前我的理解是部门 角色才能确定权限，例如管理员这个角色，每个部门都有管理员，但是我只要定义一个管理员角色就可以了，因为它放到部门下才有对应权限。而如果角色就能对应权限的话，每个部门都设置管理员的话，角色就会非常多，管理就很麻烦，部门本来就有一棵树了，角色是不是也要有一棵树呢？
我的顾虑是有理由的，但是思考不够细致。
角色对应权限的时候，角色确实会增多，但是并不会多很多，例如一个学校有20个班级，每个班级都有班主任，并不是需要设置20个班主任的角色，还是只要一个叫班主任的角色就够了。因为班级下班主任这个角色的权限可以是都一样的，而如果某个班主任还有其他额外的权限，那就再赋予额外的角色就行了。
这样角色还是能保持简单，扁平，管理也不复杂，而只用角色决定权限，显然比使用角色加部门决定权限会简单很多。
关于权限的理解
关于权限的理解，不同场景下，可能是略有不同的，通常大家可能分为页面权限、操作权限和数据权限。但是这里操作权限和页面权限或者数据权限是有重叠的，例如我们可以通过限制用户的操作来达到控制操作权限的目的，也可以通过控制数据的增删改查来达到目的。
个人认为把页面权限和操作权限合并为功能权限是比较靠谱的，那样功能权限可能组成一棵树，这也是整个系统完整的功能架构图。
关于数据权限
功能权限很容易控制用户对某个功能是否有权限，但是很难控制其对某个数据是否有权限，例如一个列表页有很多条数据，每条数据都有编辑功能，功能权限只能定义某用户是否有编辑功能，但是这很难细化到某个具体的数据，例如他可以对他本部门的数据具有编辑权限，但是对他的下级部门只有查看权限。
我们再分析一下这个数据权限，从粒度上说，通常有：表级、行级、字段级，而从类型上说，又分为增删改查。通常来说，表级太粗，而字段级又太细，实现很费事，不够实用，而行级正合适，关键是在关系数据库上很容易实现。
因此，数据权限就可以定义某用户对某条数据是否具有权限，有哪些权限等。
还有非常重要的一点，数据权限是定义在部门维度上的，例如一个人是属于某部门的，那他是否有权查看本部门数据呢，或者是否有权限查看下级部门数据的权限呢？
正确的路
因此，角色定义权限，而用户既绑定部门 角色，这样就能定义一个用户在a部门是一个角色，而在b部门又是另一个角色，灵活而不复杂。
需要注意的是这样用户就可以属于多个部门，但是用户在使用系统的时候，必须是某个部门的身份进行操作，所产生的数据和这个部门直接关联，界面功能上可以有一个切换部门的菜单。
还是以学校为例，最后可能得到一个如下的部门角色权限的图：
ps：昨晚回到住处发现手机上不了网，原来是这个月流量超过30g自动停来了……也好，不用刷手机，正好理理思路。
