权限控制的应用程序实现

于权限管理的做法，在WEB实现上，有以下几种：

　　⑴ 利用Filter，对所有进入的URI进行解析，并取得当时Session中的User信息，然后通过RBAC的机制，将此链接需要的权限与用户拥有的权限进行比较，然后进行相应的处理。这种做法有很多好处：简单，容易实现，并且对系统侵入性也不强。这里URL就是RBAC中的资源了。这样做的缺点是所有对数据的操作必须通过URL来体现，这一点在现代的程序中不太好实现。如果采用Struts, XWork或者Tapestry，采用同一个URL（浏览器看来）进行处理多项任务已不是什么稀奇的事。

　　⑵ 利用一个BaseServlet(Servlet+Jsp经典模式)或者BaseAction(Struts模式)或者BasePage(Tapestry模式)或者BaseController(SpringMVC模式)，对所有的请求先进行过滤进行权限操作，然后再处理。稍微看一下就知道这种模式跟Filter并无本质不同。优缺点同上。

　　那么，如果要实现更为细致的权限操作，精确到某个方法的权限，典型的做法如下：

public someFunciton() {
　//权限判断
　User user = context.getUser();
　if (user.canExecuteThisFunction()) {
　　// do the business method
　　// ...
　} else {
　　throw new PermissionDeniedException();
　}
}
　　这种做法能够将权限的粒度控制到具体的业务方法，因此它的控制能力应该是强大的。可以看到，权限判断部分对于每个方法几乎是独立的。

　　这种在具体功能前加入权限操作检验的实现方式有很多缺点：

　　⑴ 每个功能类都需要相应的权限检验代码，将程序功能和权限检验混淆在一起，存在紧密的耦合性，扩展修改难度大。

　　⑵ 以代理模式为每个功能类实现一个相应的代理类，虽然解耦了程序功能和权限检验，但是，从某个角色的权限检验这个切面考虑，涉及具体Proxy类太多，扩展修改难度大。

　　权限控制的J2EE容器实现

　　在AOP概念没有诞生前，J2EE规范已经提供了关于权限控制的容器实现标准，这种变迁结果如下图所示：

图2 权限控制的J2EE容器实现

　　原来需要每个应用程序实现的权限Proxy转为整个容器的Proxy实现，其中JDK1.3以后的动态代理API为这种转换实现提供了技术保证。

　　非常明显，通过容器实现权限控制验证可以大大简化应用程序的设计，分离了应用系统的权限关注，将权限控制变成了对J2EE容器服务器的配置工作。

　　其实，容器的权限实现也是一种从一个侧面来解决问题方式，AOP概念诞生后，权限控制实现由此也带来了两个方向的变化：

　　⑴　J2EE容器级别的权限实现，也就是容器自身的权限实现。

　　⑵　J2EE应用程序级别的权限实现。

　　权限控制在容器级别实现似乎使得J2EE开发者感觉没有灵活性和可扩展性，其实象JBoss 4.0这样的J2EE容器，由于引入了AOP概念，使得J2EE开发者在自己的应用系统中能够直接操纵容器的一些行为。容器和应用系统由于AOP引入的Aspect切面，变得可以成为一体了。

　　对于J2EE应用系统开发者，能够做到上述境界，必须的条件是对JBoss之类J2EE容器必须有足够的了解，因为这些方式并不是J2EE标准，有可能在移植到新的J2EE容器，这些知识和投入变得无用（也有可能将来J2EE扩展其标准）。

　　很显然，使用AOP实现J2EE应用系统级别的权限控制，是解决上述移植风险的一个主要方法，但是带来的缺点是必须亲自从零开始做起，耗费时间不会很短。

　　AOP下的权限控制实现

　　有了AOP，新的业务方法可以这样写：

public someFunciton() {
　// do the business method
　// ...
}
　　没有了额外的权限操作，这个业务方法看起来那么清晰自然。

　　将对权限的操作作为一个Advice，并将Advisor关注到所有的业务方法（可能有某一个特定package），然后，剩下的事情就由RBAC以及AOP来完成了。通过这样的分离，纵向的一个业务方法被分割为一个更为自然的业务方法和一个关注点。这个关注点写法可能如下：

public class PermissionCheckAdvice implements MethodBeforeAdvice {
　public void before(Method arg0, Object[] arg1, Object arg2) throws Throwable {
　　//权限判断
　　if (!this.getContext().getUser().canExcute(this, arg0)) {
　　　throws new PermissionDeniedException();
　　}
　}
}
　　可能有个问题：如何取得context或者当时上下文环境的User呢？答案是使用IoC（或称Dependency Injection），将上下文环境或者User作为参数反向传入到逻辑方法中。当然，在传入之前，这些变量是需要初始化的。这个初始化工作可以在SuperServlet中进行，并且以Session单例的形式保存在应用程序中。下面是Spring配置文件的例子：

＜beans＞
＜!-- Bean configuration --＞
＜bean id="businesslogicbean"
class="org.springframework.aop.framework.ProxyFactoryBean"＞
＜property name="proxyInterfaces"＞
＜value＞IBusinessLogic＜/value＞
＜/property＞
＜property name="target"＞
＜ref local="beanTarget"/＞
＜/property＞
＜property name="interceptorNames"＞
＜list＞
＜value＞thePermissionCheckBeforeAdvisor＜/value＞
＜/list＞
＜/property＞
＜/bean＞
＜!-- Bean Classes --＞
＜bean id="beanTarget" class="BusinessLogic"＞
＜property name="user"＞＜＜YOUR USER OBJECT＞＞ ＜/property＞
＜/bean＞
＜!-- Advisor pointcut definition for before advice --＞
＜bean id="thePermissionCheckBeforeAdvisor"
class="org.springframework.aop.support.RegexpMethodPointcutAdvisor"＞
＜property name="advice"＞
＜ref local="thePermissionCheckBeforeAdvice"/＞
＜/property＞
＜property name="pattern"＞
＜value＞.*＜/value＞
＜/property＞
＜/bean＞
＜!-- Advice classes --＞
＜bean id="thePermissionCheckBeforeAdvice"
class="PermissionCheckBeforeAdvice"/＞
＜/beans＞
　　结束语

　　AOP引进了Aspect，它将影响多个类的行为封装到一个可重用模块中，它允许程序员对横切关注点进行模块化，从而消除了OOP引起的代码混乱和分散问题，增强了系统的可维护性和代码的重用性。利用AOP的拦截（interception）能力，它为我们提供了“在任何对象的方法调用前/后加入自定义行为”的能力，这使得我们可以处理企业应用中的权限控制这一横切关注点，并且仍然保持强类型（不需要改变方法签名），解耦了程序功能和权限检验。