I just finished my chapter on security for Spring Live - do you think I should scrap the old stuff and update it to reflect this "new way"? If so, when will 0.8.0 (or will be it 1.0) be released? I know the answer is probably "when it's ready", but it can't hurt to ask. ;-)
Matt
Ben Alex wrote:
I've just committed to CVS a FilterChainProxy class, docs and tests which make web.xml significantly simpler for Acegi Security-based applications. It means you only need a single FilterToBeanProxy in web.xml, which delegates to your FilterChainProxy. The FilterChainProxy is defined like this:
<bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">
<property name="filterInvocationDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/webServices/**=basicProcessingFilter,httpSessionIntegrationFilter,securityEnforcementFilter
/**=authenticationProcessingFilter,httpSessionIntegrationFilter,securityEnforcementFilter
</value> </property> </bean>
It's fairly self-explanatory if you think of SecurityEnforcementFilter. The first entry matching the request pattern is used, and the configuration attributes define the application context bean names of filters to be executed. Filters are executed in the order they're declared. This really tidies up web.xml. The Contacts sample application demonstrates the approach.
On a related matter, I've addressed the IoC container vs servlet container lifecycle issue. Now FilterToBeanProxy does NOT call init(FilterConfig) and destroy() unless the optional "lifecycle" initialization parameter is set to "servlet-container-managed". This means the IoC container is preferred for managing the lifecycle of proxied filters. I thought this was the right approach given (i) IoC containers provide a far richer and more predictable source of IoC / lifecycle interfaces than the servlet spec offers; (ii) the parameter can be set to invoke the servlet spec lifecycle methods if desired; and (iii) most Filters loaded with FilterToBeanProxy should expect to be hosted by an IoC container and would probably prefer the richer interfaces such a container exposes (certainly all the Acegi Security filters use the Spring interfaces and no-op the two servlet spec lifecycle methods). I did of course consider just changing the FilterToBeanProxy model - and make all delegates implement a "SimpleFilter" one-method interface instead of Filter - but I know many people use FilterToBeanProxy for "legacy" filters and it seems desirable to keep this functionality. Any comments are welcome.
Best regards Ben
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
