重写了一遍授权思路

AuthorizationCore

授权项目

通过将授权项、角色、相应对象相关联的方式来判断，请求对象是否有权限进行相应的操作。

项目分析

简单点说授权就是一个对象（可能是个人；可能是个角色），在进行某件事情之前，根据一定的数据设定计算，被请求对象（动作的依附对象，可能是一个文件也；可能是某一个类文件；）的某一个动作（可能是文件的读写；可能是某一个方法）是否有权利完成。

名词简介

请求对象

自然人

张三、李四某一个系统中的具体的用账号密码登录的人员都可以被认为是自然人。

角色

某些情况下我们可能非常难做到自然与实际的被请求对象之间的关心，因为这实在是一件太庞大的数据了。比如张三对于张三的博客是博主，所以张三对于张三的博客拥有管理权限。但是李四并不是张三博客的博主，所以李四并不能管理张三的博客。我们可以直接对张三跟战三的某一篇博客建立请求与相应之间的关系，但是这个数据量会变得非常庞大。所以某些情况下，我们只能先通过数据计算张三与战三博客的关系，然后在通过这个关系来判定数据的权限。

其他

当然这个地方可以存在其他，请求对象只是一个请求对象而已。比如说，我们现在要建立一个平台服务，这个服务可以提供很多API给其他的系统，但是每一个系统所能调用的API接口不尽相同。那么，我们怎样通过我们的授权服务来判定哪几个接口可以调用，哪几个不可以呢？比如我们可以将某一个系统作为一个请求对象来调用服务，就可以做到相应的权限管控了。当然还有很多很多其他的情况，我在这里只是简单的举个例子，为大家抛砖引玉

响应对象

既然存在请求，那么相对的就会存在响应对象。那么响应对象一般情况下可以是什么呢？

具体的响应对象

具体的响应对象可以是某一个文件，比如你想删除掉这个文件，我们就可以具体判断你对这个文件是否拥有某些权限，这个时候文件就是一个响应对象。也可以是一个组织，比如你想操作这个组织，修改这个组织的头像。这个时候这个组织就是一个具体的响应对象。

逻辑意义对象

就像是我们在 请求对象-角色 中提到的那样，很多时候我们并不能规定某些具体的人对于某些具体的对象的权限，因为这些对象实在是太多了，如果动态的维护这些数据，那是一件非常痛苦的事情。所以我们提出了上边的对象概念，那么久会扯出来另一个概念，逻辑意义对象，张三的博客对于张三来说，实际上就是自己的博客。当然李四的博客对于李四来说也是自己的博客，从这个地方上来讲，这两个自然人对于这两个实际的对象拥有相同的授权。自己的博客并不是特指某一个具体的对象而是指某个逻辑上的对象。

某些业务场景

像是前文中提到的某一个类中的函数允不允许调用的问题。这个时候就是某些业务场景。当然这个可以认为是某一个具体的响应对象，毕竟那个类就是那个类。不过这个地方因为不牵扯到具体的类的实例，所以还是单独拿出来归为一类比较好

其他

……

角色

这个角色有别于之前提到的角色，但是两者非常类似。角色定义为某个人拥有的身份，比如说，张三是张三儿子的老师，那么张三对于张三儿子就有多个身份：父亲、老师、可能还有朋友。假设我们来规定不同的身份对于战三的儿子拥有不同的权利。那么张三对于张三儿子的权利还蛮多的毕竟身份也有很多。

角色

角色对于角色这个地方可能非常容易理解，因为角色就是角色嘛。不过角色还会支持一个高级特性。权限合并这个一会我们在讲。

个人

某些情况，我们需要给某一个人进行授权，这个时候我们可能需要创建一个对象，专门用来表示这个个人。因为个人表示某一个个人，所以个人与个人之间并没有什么直接关系。比如说张三和李四，他们之间除了都是人可能也没有啥太特殊的关系。

组织

一般情况下，个人也好。请求对象中的角色也好，一般都是归属于某些组织的。当然组织是在其他系统中实现的，组织的内容我们不做过多的展开，组织的概念呢就是根据这些组织结构相对应的角色对象。比如说，张三归属于红星公司的研发部。这个地方可能就会产生两个角色，红星公司跟研发部。而张三则因为组织结构的原因会被设置到研发部这个角色下拥有研发部角色的相关权利。

权限继承

角色篇章里边，我们提到了战三与研发部的关系。不过张三只属于研发部嘛？应该不是，研发部属于红星公司，那么张三自然也就属于红星公司。那么我们现在有两条路可以选，张三可以同时拥有两个角色，我们将两个角色的权利合并，我们就可以得到张三的的所有权利。另一条路，张三属于研发部，研发部属于红星公司，将红星公司的权利赋予研发部，那么张三自然拥有了所有的权限。其实想来看看，如果组织结构层级非常深的情况下，那么张三会拥有非常非常多的角色。这也是一件非常恐怖的事情，所以我们要走第二条路。其实不光是组织，所有的角色对象都应该是这样的，不过，讲道理个人不应该被继承。

权限合并

讲完了继承，我们该讲讲合并了。张三跟他儿子的关系的时候，我们就提到了很常见的情况就是一个请求对象对应一个相应对象有非常多的角色。当你想验证你做一件事情是否拥有权限的时候，就应该将你所有的权限合并起来，然后综合来看你对想做的事情究竟拥有怎样的授权。

权限的状态

在讲合并之前得先讲讲权限的几种状态：未定义、通过、拒绝。

未定义

这事我不管你们看着办，行也可以，不行也可以。

通过

好了我觉得这事能行。

拒绝

不行这事不行

合并

• 只要所有的授权项中有一项是拒绝的，那么整个授权结果都是拒绝的。
• 如果所有的授权项中都是通过或者未定义则将授权项定义为通过。
• 如果所有的授权项都是未定义的，则合并结果为未定义。

后边两条或许还好理解一些，第一条则需要着重解释一下。其实这个地方来源于两个概念，黑名单和白名单。他们分开使用的情况下应该非常容易理解，但是他们一旦一块使用了，并且同一个人出现在了两个名单里边，就让人难以抉择了。那么我们应该怎么办呢，让我们先看一下后边的例子。

让我的老师远离我的QQ空间：
你申请了一个QQ，你有一个QQ空间。但是你不想让你的老师看到你的QQ空间。其他人是无所谓的，那么一般情况下会这么设置：1.任何人都可以看；2.我的老师不能看；这个时候你的老师就会出现在两个冲突的授权中（你的老师是所有人的一员，你的老师也是你的老师）。在这种情况下我们取什么值呢？答案很显然是不通过，否则就违背了我们的本意。

多群组：
张三同时加入了两个组织，而这两个组织是相互有利益冲突的。假设他们现在建立了一条规矩，说属于对方组织的人是不能够访问我们的资源的；我们自己组织里边的人时可以访问我们的资源的。那么拥有两个组织的资源访问权限吗（毕竟他既属于自己的组织又属于对面的组织）？其实考虑这个问题应该从设置规矩的出发点上来看待这个问题，其实就是害怕对方的组织访问了自己的东西，而给自己的组织造成了利益上的伤害。那么从这个角度出发张三是没有权限的。
或许你会考虑张三既然属于了组织那么就应该享有权利，如果不想让张三拥有权利，可以通过某些授权来解决问题

其他的手段保证合并

• 不让战三加入组织。确实可以解决，并且大部分情况下组织如果有冲突的话，一般情况下也确实不会让他们相互加入，但是在某些情况下是没有机制保证这件事情的。所以这种做法可能没有照顾的那么全。
• 踢出授权范围。比较常见，比如说除了张三的所有人都享有权利。但是这个在数据表达上可能就比较困难。虽然可以做，但是相关的表达这句话的程序数据模型就会变得非常复杂，所以也比较困难

授权项

其实讲到这里，缺少什么也应该比较清楚了。就是缺少了具体的动作。比如说访问资源、访问QQ空间。这些都是依附在响应对象上的具体动作。

授权项的依附

授权项是依附在响应对象身上的。回到最开始的文件案例上来。某一个具体的文件上的读、写、删这些授权项都是依附在某一个具体的文件对象身上的。

权限项的分类

其实相同的内容会有相同的权限项。比如文件类型的响应对象，那么无非也就是读、写、删这么几个动作。别的你应该也没有办法弄对吧；那么对于QQ空间来说就是被访问；响应对象应该会存在一个类型，然后授权项的模板应该是依附在相应对象类型身上的。

END