设计@权限设计的一些想法和思考 |美好，一直在身

作者：cross
my.oschina.net/cloudcross/blog/1920706
这篇文章的定位，不是宣传某个框架，仅仅之是梳理一下有关权限方面的一些想法和最近项目中的一些探索过程。我们主要想解决一下问题。

什么是权限，程序员理解的权限和客户所理解的权限是不是一致的。
权限的划分原则，权限到底是根据什么原则进行组合的。
角色是用户与权限之间的必要的关系吗？角色到底承接了什么作用。
如何进行合理的表设计。
安全框架。

1.什么是权限在很多与开发者也好，与客户也好，沟通的过程中我们很多次提到了权限，但是权限具体的含义每个人理解的含义都不明确，这样很容易造成双方信息不对称，有的人就只是把权限理解成某个页面的是否可访问，但是有的人却理解成其他的东西。所以我们要彻底的定义一下权限是什么。
权限到底是名词属性还是动词属性，还是名词、动词属性均包含，这对于权限的含义很重要。如果是名词属性的话，那么它应该是有具体的指代物；如果是动词，则应该具有行为表示。

权限的名词属性：api接口、页面、功能点。
权限的动词属性：可操作、不可操作。

那么我们现在来看，其实权限是名词、动词属性，它一定是表达了两层含义。即控制的对象、操作。
例如：权限A表示页面A的可访问。例如：权限B表示页面B可访问且页面内的功能b不可使用例如：权限C表示接口C不可调用。例如：权限D表示页面D可访问，且接口D可访问。
那么进一步的说明，权限可以表示单个控制的对象的操作集合，也可以表示多个控制的对象的操作集合。而这两者的取舍则是有设计人员决定的。

本文插图

一句话总结权限的含义：what（若干元素）进行how（若干操作）
2.权限的划分原则我们了解了权限的具体含义之后，接下来就是用的问题，我们该如何去使用权限，如何将系统中的操作元素进行一个组合，这个我借鉴网上的一篇文章来解释。划分原则可以按照“最小特权原则”和“数据抽象原则” 。
最小特权原则
1、我先举一个反例，我把系统中所有的元素和操作都组合成一个权限。一个用户拥有这个权限就相当拥有了系统所有的功能，实际上这肯定是不行的，用户在一套系统中一定有他不允许操作的内容，哪怕是超级管理员也可能会有不能操作的元素，那么最大化权限则是行不通，因为不符合常理。
2、据此，我们就把权限再进行一个拆分，按照业务模块进行拆分，但是这实际上也是不行的。就比如系统中的财务模块，假定模块中含有报销页面和申报页面，如果按照模块进行拆分，那么肯定有用户同时包含了两个互斥功能。
3、根据1和2 ，我们需要按照最小化进行权限划分。但是这个也是值得商榷的，因为不同系统，最小的权限划分对于提供的功能来说，划分的角度也是不同的。
数据抽象原则
1、“最小特权划分”从某个程度上来说决定了控制的对象，而数据抽象原则是是决定了操作。
2、数据抽象从字面的意思来看，其实很难理解到底是什么意思。通常我们口头上说最多的是CRUD增删查改，这实际上就是数据抽象的一种，我们可以理解成元素操作许可权的意思。
3、但是CRUD并不是数据抽象的全部，增删查改用于单实体，基本是没问题的，但是在构建关系上，其实是不够用的，例如任免某个经理管辖某个部门，从业务表面而言它修改了经理的管辖范围。但是从代码底层构建上来说，它属于在经理和部门间新增了一道关系，所以根据需求我们需要再额外的增加一类许可权“任免许可” ，这一类型的扩展则需要根据系统实际的业务情况进行划分。