Acegi(十二):anonymousProcessingFilter有什么好玩的?[Java编程]

在这篇博客中, 我们接着看另一个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.

Xml代码

<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

Xml代码

<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.