Re: [Acegisecurity-developer] Reducing the number of filters needed in web.xml
This looks very cool - anything to cut down the amount of XML needed for Acegi Security is a good thing IMO. 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=6595alloc_id=14396op=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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Reducing the number of filters needed in web.xml
Robert r. Sanders wrote: While I don't have a huge amount of spare time, I would be glad to look over any list of tasks you have and see if I could fit any of them in. I tried to look on the sourceforge site and see if there were any bug/feature lists but couldn't find any. Hi Robert Given your recent interest in the LDAP module, and its significant usefulness to the wider community, I think that's good feature to move from sandbox to core. Some things that might need doing in that regard include checking the forums for past LDAP contributions (to check the current LDAP DAO provides equivalent features), a description for the reference guide, and a unit test. Re unit testing, the problem is the difficulty of needing an LDAP server to respond to the requests. I see a few approaches that we could investigate: - Expect an LDAP server to be running. A Win32 port of OpenLDAP is available at http://lucas.bergmans.us/hacks/openldap/. I wouldn't mind if it was a prerequisite that the server was already running, with a base schema and users already in the directory. In this case we might make the LDAP module a separate Maven subproject so that it doesn't interfere with core's unit tests. - Look at Apache Directory Server. Maybe it could be loaded in-memory during the test. I haven't looked into it, but this is attractive being an all-Java solution. http://incubator.apache.org/directory/ - Review Olivier Jolly's LDAP support classes at http://www.uportal.org/cgi-bin/viewcvs.cgi/cas3/adaptors/ldap/src/. I took a look and they seem interesting - probably worth using in our LDAP DAO interface anyway just for completeness. Perhaps we could mock one or two of the key interfaces and not use an LDAP server at all. I'm quite keen on getting this LDAP issue sorted out, so any time you could invest in that would be greatly appreciated. Here is the remainder of my TODO list (not all of which will be done before 0.8.0 or even at all). I am working on the three items marked ***: *** Digest authentication (for WebDAV compliance) http://www.ietf.org/rfc/rfc2069.txt *** Anonymous user provider, so there's no need to exclude web URIs http://forum.springframework.org/viewtopic.php?t=1925 *** Remember me functionality http://sourceforge.net/mailarchive/forum.php?thread_id=5177499forum_id=40659 http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice Chain AuthenticationDao / AuthenticationProvider (regular forum question) Eliminate hard-coded exceptions in AbstractProcessingFilter (replace with a pluggable resolver that is wired via a property editor) Certificate integration (seems complicated as exchange happens in container-level SSL/TLS handshake) Prevent concurrent logins via a session listener (committed new WebAuthenticationDetails which stores session ID in Authentication) JMX of cache hits/misses, password failures, prevent user logins not holding certain role http://opensource.atlassian.com/confluence/spring/display/DOC/Exposing+your+Beans Tiger annotations (or just wait for Spring to provide guidance on how it will approach this) DB source ObjectDefinitionSource (or just let Spring do it at container level) JOSSO Integration (good marketing benefit for software developers wanting pluggable SSO solutions) SecureID Integration Any help appreciated! 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Reducing the number of filters needed in web.xml
Dmitriy Kopylenko wrote: Ben, how about start using JIRA for Acegi release/issue management? I could create a project for JIRA in Spring JIRA installation. Would it be appropriate, taking into consideration that Acegi is not the official Spring subproject? Dmitriy. Thanks for the offer, but perhaps just hold off for the moment as I anticipate the subproject status will be sorted out in the very near future. :-) Cheers 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
