Acegi(十二): anonymousProcessingFilter有什么好玩的?

    在这篇博客中, 我们接着看另一个Filter, anonymousProcessingFilter.

    1, 为什么要配置这个? 它能给我们带来什么好处?

    为了解决这个问题, 看了下Acegi的文档 , 但说实在的, 由于文档中用是"convenient"和"nice"这样的词来描述这个filter的好处, 我现在还感觉不到. 这里把我现在给想到的理由总结一下.

• 为了理论上的完美. 用了这个fitler,就可以对系统中所有 的 链接加权限管理了, 像login, logout和home这样的"非常规访问",也可以加一个默认的匿名访问Authentication. 像这样的"非常规访问"是可以在acegi的配置文件中写死的, 当然写死有写死的坏处. 由这个坏处,我们看下一个理由.   
  
• 为 了某个链接的动态设定. 可能会有这样的情况: 一个链接的访问权限刚开始时是有专门的访问权限的, 但由于业务逻辑的变更, 这个链接的权限改为匿名的了,或者说原来的匿名访问要改为具有一定权限访问了. 这时, 为了在不重启服务器情况下设定权限, 就预先配置一个anonymousProcessingFilter, 让它来处理那些默认的情况.
• 别的我现在猜不出来了, 希望大家能补上.
  

    2, 怎么配置?
    虽说不是很理解, 但还是要配置的. 那怎么配置呢? 我们先看这个filter所涉及到的三个类: AnonymousProcessingFilter, AnonymousAuthenticationToken,AnonymousAuthenticationProvider. 第一个类没什么说的, 它就是这个filter的实现类, 没有它办不成事. 第二个类实际上是一个Authentication, acegi通过它来加一个默认的匿名Authentication. 第三个类实现了AuthenticationProvider接口, 有了一个匿名的Authentication, 相应地得给一个Provider, 以便在filterInvocationInterceptor检查权限时,被"卡"住. 呵呵, 看到这, 我觉得挺好笑的了: 本身是一个虚头八脑的东西, 为了"掩盖"它, 让在真实世界里行的通, 还得再给弄两个一样虚头八脑的东东陪着.
    有了一种大致的了解后, 我们看配置:
    2.1 配置anonymousProcessingFilter bean.

   

<bean id="anonymousProcessingFilter" class="org.acegisecurity.providers.anonymous.AnonymousProcessingFilter">
        <property name="key" value="anonymous"/>
        <property name="userAttribute" value="anonymous,ROLE_ANONYMOUS"/>
</bean>

 

•   这两个Property, 都是在生成AnonymousAuthenticationToken时用到.    userAttribute中的anonymous对应着Authentication(AnonymousAuthenticationToken也是 一种Authentication,虽说有些虚)的principal, ROLE_ANONYMOUS对应着Authentication中的GrantedAuthority[],  key的anonymous生成AnonymousAuthenticationToken中的keyHash(通过String类的hashCode方 法获得).
• <property name="key" value="anonymous"/>与下面配置的anonymousAuthenticationProvider中的相应行对应.
  

    2.2  配置anonymousAuthenticationProvider

<bean id="anonymousAuthenticationProvider" class="org.acegisecurity.providers.anonymous.AnonymousAuthenticationProvider">
        <property name="key" value="anonymous"/>
</bean>

 

• 配 置好后, 把这个anonymousAuthenticationProvider配置到ProviderManager类下providers, 这样filterInvocationInterceptor碰到前面配置的匿名Authentication时, 才能在AccessDecisionVoter"投票"时, 由AnonymousAuthentication的自己人anonymousAuthenticationProvider"保护"着"逃过 "check.
• 一个猜想: 这里的key跟上面anonymousProcessingFilter的key得一致, 不然在"投票"时, 没这个"暗号""自己人"也互相不认识了.想验证这个猜想, 看了下文档,发现这样的话: "The key is shared between the filter and authentication provider, so that tokens created by the former are accepted by the latter".自己的猜想不错!
  

   
  有了上面的配置分析, 运行机理稍看下源码就可以明白了, 这里也就不用再另写了.

-----------------------------------------
看文档时发现这么段话, 觉得很有必要记下来,虽说现在还没有切身体验:Rounding out the anonymous authentication discussion is the AuthenticationTrustResolver interface, with its corresponding AuthenticationTrustResolverImpl implementation. This interface provides an isAnonymous(Authentication) method, which allows interested classes to take into account this special type of authentication status. The ExceptionTranslationFilter uses this interface in processing AccessDeniedExceptions. If an AccessDeniedException is thrown, and the authentication is of an anonymous type, instead of throwing a 403 (forbidden) response, the filter will instead commence the AuthenticationEntryPoint so the principal can authenticate properly. This is a necessary distinction, otherwise principals would always be deemed "authenticated" and never be given an opportunity to login via form, basic, digest or some other normal authentication mechanism.