权限处理模型

　

上图虚线为期望目标，实线为真实处理规则路径

　　最近经常会处理一些关于权限的问题。在此整理下工作过程中的一些想法。

　　就我个人理解，关乎权限的处理，无外乎把握住3点，第一个应该就是人了，在此称为被申请单元；另一个就是就是权限检测的逻辑处理了，在此称为处理单元；最后一个就是权限检测通过之后我们的获取到的目标数据了，在此称为目标单元。

　　那么所有的权限逻辑都可以称之为申请单元针对于目标单元要达到某些目的，在此过程之中需要通过某个处理单元的检测规则。

　　当我们在一个系统中可能会遇到很多的权限问题，一般来讲我认为都可以找到当前系统中的申请单元，这个大部分的情况下都是操作人。然而目标单元在一个系统中可能会存在很多种。简单来讲就一个客户信息管理系统来讲。那目标单元就包括客户、联系人、详细说明等等。

　　在这种情况下我们的目标单元就会是客户信息，联系人信息，详细信息。这个时候一般系统处理过程中会出现3中ID，此时就引出了3种的处理单元，但是从某种程度上来讲，我们有这个客户的权限的时候基本上其他的权限我们也是应该有了的，那这个时候，我们真是的处理单元应该说就只有一个，那就人–客户的权限认证。另外在此基础上，我们还需要的就是对这个认证规则之前做一些处理，把联系人，详细信息这类的数据转化为人–客户的认证，也就是联系人ID转化成客户ID，而且这个还必须是在客户认证逻辑之前。这样基本上系统的权限检测就很简单了，从开始的时候只要分析出来，当前系统有哪些申请单元，哪些目标单元，然后分析，申请单元到目标单元的处理规则是否有共性，从而可以决定由几种基本上处理单元，然后在给每一个处理单元，提供一些开放的转换规则扩展，那么一个基本上业务系统公共鉴权的组件就差不多完成了。

　　核心的功能支持，申请单元的获取方式，要支持自定义扩展。另外就是申请单元和目标单元之前的直线连接可以通过某些前置处理之后把真正的检测逻辑合并，也就是说在申请单元和目标单元中间添加一个类似于路由的控制即可。

　　另外简单介绍下大概会用的的技术，像这种的公共组件性质的代码一般追求对代码侵入性小，接入简单，实现方便等等。基本上就是AOP拦截控制+注解，一般是扫描+指定注释两种。扫描的方式支持的公共性特别强的业务，指定注释的方式可以支持更多代码在系统中随机路径分布的情况下的实现，相对更灵活，但是侵入性相对大一些