java动态代理实现Authorization(授权)

动态代理实现Authorization（授权）*ng.reflect包中的 Proxy和InvocationHandler接口提供了创建（指定类[接口更准确些]的）动态代理类的能力。

我们知道，对象是类的实例，一般使用内存来模拟对象，对象是依据类为模板来创建的，创建时使用new来分配一块内存区（其布局参考相应类的内存布局），为变量做一些赋值便是对象的初始化了。

我们知道通常类是设计时的产物，在设计时我们编写对象的模板（即——类），运行时产生类的实例。

类所处的文件是 .java文件——源文件，之后编译为jvm-----java虚拟机可解释执行的.class字节码文件，在类解析过程中这些.class文件由类加载器加载到虚拟机（可实现自己的类加载器来加载处于特定路径下的类，或加载用某种加密算法加密过的类文件---这样便于进行安全控制——具体描述参考（Core java ——Java核心卷二））。

在遇到创建对象的指令时使用加载的类来创建对象内存空间。

动态代理是不用创建类文件（当然也不用创建java源文件），就能在虚拟机中构造出类文件区域来（相当于使用Proxy类来创建一块类内存区域，该区域中的内容相当于加载某个.class文件产生的区域；比如我们在使用DOM技术时，从一个XML文件构造一个DOM内存表示，它是XML文件的内存表示，但我们也可以直接使用DOM API在内存中构建一个dom树，最终结果就是一个内存DOM树，你不用关心这个dom树是来自于xmL文件还是直接的运行时构造）。

***关于代理设计模式，这里不再敷述。

代理和被代理类（目标类）实现共同的接口。

我们在调用时不需区别它是否是真正的目标对象。

代理会转发请求到目标对象的。

比如互联网上的代理服务器，我们不必关心它是不是代理，就当它不存在一样。

对客户调用端他是不关心具体是谁来提供这个服务功能；在服务端选择使用代理的原因可能是：安全，日志，防火墙等。

就是说代理可提供一些非功能性功能，比如缓存功能____来加速服务的响应的速度。

在面向方面技术（AOP）中这些非功能性需求被称作“方面”他们横切于功能类的实现中，比如：某个SubServerImpl（子服务实现）中的某个服务方法：subServer.doService(){//在日志输出中常有类似的代码出现于多个类实现中loger.log("<enter 该方法被调用");//doSomeThing();loger.log("方法调用结束 end>");}如果已经存在了一个服务实现，你还需要加入日志功能，而又不想改动既有的实现，也不想太多的改动客户端，我们可以引入一个代理类：class SubServerProxy extends ISubServer{ISubServerProxy target;public SubServerProxy(ISubServerProxy target){//代理依赖于具体的子服务实现，至于设值依赖的接口这里就不给出了//这里只提供构造子依赖注入的接口。

this.target=target;}public void doService(){//实现接口loger.log("<enter 该方法被调用");this.target.doService();//这里先记录日志，在将具体的操作委托给目标对象。

loger.log("方法调用结束 end>");}}对于客户代码，以前可能是这样：class Client{public doSomeThing(){//你或许处于网络环境中，可能使用了名字服务，那么改这里的new操作为Lookup即可；ISubServer server= new SubServerImpl();}}引入了代理后只需要改为： ISubServer server= new SubServerProxy();即可，之后的代码不需要改动依据是 Liskov替代原理（请参考Robert Martin的《Design Principles and Design Patterns》___google直接搜索该文章）。

由于我们在客户端依赖了抽象（即直接使用了继承层次树中的根——ISubService）。

*****上面给出了代理类的一些常用的用途，可以看出这样的非功能性需求会出现在很多代码中，我们不得不在多个类的多个方法中加入这些讨厌的重复代码，并且可能实现多个代理类（代理本身仍旧可以选择再使用其他的代理，每个代理完成不同的方面，随后我会使用动态代理来展示这点的）。

这样代理类的数目急剧膨胀，加大了维护和开发投入。

借助动态代理类我们不需要为每个意欲附加非功能性需求的类来在运行时生成一个动态代理。

并且你还可以在以后重用InvacationHandler实现。

以下讨论本篇的重点。

:-）*******关于 Authorization（授权）：许多软件系统中，我们都需要授权访问功能，允许某个特定用户访问特定的功能集。

将整个系统对用户提供的功能，看作一个集合，这些集合中其中一部分对该用户可以访问，另一些对该用户不可以访问。

最完美的访问控制技术，当然是实现访问控制矩阵。

替代的ACL访问控制列表也可以实现。

访问控制矩阵概述：矩阵分两个轴，随便一个轴列出所有的主体（如可以是userName），另一个轴给出系统提供的所有客体（功能单元），在矩阵交叉的单元是 1，或0；1表示主体可以访问该客体，0表示主体不可以访问该客体。

ACL访问控制列表概述：由于访问矩阵中0出现的很多，在使用矩阵结构时造成大量的空间浪费，即稀疏矩阵。

我们只记载访问控制矩阵中是1 （当然也可以是0）的主体和客体，这样我们在一个轴向上使用一个列表来存放所有的主体或客体，每个列表中的单元上还有一个列表，其中给出了该主体（或客体）能够访问的客体（或可访问该客体的主体）。

伪码实现：class AccessRelationEntry{//该类表示一个访问关系的入口User user; //表示主体List<Object> objectives;//这是一个客体列表public AccessRelationEntry(User user){er=user;this.objectives=new List<Object>();}//该方法可将一个客体加入到某个主体可访问的列表中去public void addObjective(Object objective ){this.objectives.add(objective);}public User getUser(){return er;}public boolean hasPermission(Object objective){return this.objectives.contain(objective);}}以上只是在一个轴的实现，另一个轴如下：//该类其实可以实现为一个全局共享的静态类，方法全为staticclass ACLManager{List<AccessRelationEntry> acl=new List<AccessRelationEntry>();public void addAccessRelationEntry(AccessRelationEntry aRE){this.acl.add(aRE);}public boolean hasPermission(User user,Object objective){//看某个特定用户和对象是否出现访问控制列表中//出现则表示有权限，否则无权限，当然也可反逻辑实现。

//遍历访问控制列表for(AccessRelationEntry are:acl){if(are.getUser().getName().equals(user.getName())){return are.hasPermission(objective);}}//遍历完成，如果函数仍未返回表明，没有指定的用户，处理略...。

}}*********Authorization设计模式（详见POSA卷四）：对于系统中子系统提供的功能，并非每个客户端都能够访问，对于一些敏感的信息（如：工资，医疗信息等），仅授权用户才可访问。

对于提供这样服务的模块（或称为组件，子系统等），将“trusted”client硬编码到组件中是很笨拙且高维护代价的一种实现。

（即将每个可访问该客体的主体信息硬编码到该组件的实现中）。

所以：将访问权限赋予可访问安全敏感的子系统的用户，并在在子系统上执行任何请求之前检查用户的权限。

由高权限用户来为普通用户授权；在每个组件（或称子系统）的每个方法调用之前执行权限检查；伪码如：class SubSysImpl{public void doServiceA(){/* <start 权限检查*/User user=AppContext.get("currentUser");//获取当前的用户if( ACLManager.hasPermission(user,"SubSysImpl.doServiceA"){//查询访问控制列表管理器，该用户对该方法是否有访问//权限，如果有则继续其他的正常操作，否则抛出访问拒绝异常（自定义的）.....Execute normal action}else{throw new AccessDenyException("你无权访问"+this.getClass().toString); }/* 权限检查 end> */}}授权设计模式的主要优点是，仅有授权的用户才可访问该子系统，这对安全敏感的应用系统很重要，另一个优点检查特定的访问权限（或policies）可对客户和组件透明。

对授权基础结构实现的通用形式是ROLE-BASED ACCESS CONTROL（基于角色的访问控制）。

不是把单个访问权限（AccessRights）赋给每个用户，在系统中定义了一些角色集（如：administrator，power user，guest等），用户（User）可与某个角色关联，每个角色对应了一些访问权限集。

REFERENCE MONITOR补充了授权体系结构，所有的用户请求都会被一个中央引用监视器“拦截”，拦截后检查用户的访问权限是否与应用的授权规则一致。

这种设计集中化了访问权限的检查对每一个客体都需要（必要时）先通过monitor的检查，然后才可访问。