Re: [Acegisecurity-developer] Reducing the number of filters needed in web.xml
OH, also, sorry, I have an RFE on my work project for one-session logins as well. If I make any progress with that I'll let ya know. On Mon, 21 Feb 2005 08:02:57 -0600, Ray Krueger [EMAIL PROTECTED] wrote: I don't have a ton of free time either, but count me in Ben... Where can I find some more information on the Certificate Integration? I'll volunteer for the AbstractProcessingFilter exceptions. We're gonna need Jira, or you're gonna go nuts... -Ray On Sun, 20 Feb 2005 21:20:18 -0500, Scott Battaglia [EMAIL PROTECTED] wrote: Ben, Just a note that the official source that Olivier posted for LDAP support is here: http://opensource.atlassian.com/projects/spring/browse/SPR-362 The one's we're using, which are slightly modified (to include LdapDaoSupport) are here: http://www.uportal.org/cgi-bin/viewcvs.cgi/cas3/adaptors/ldap/src/main/java/org/springframework/ldap/ I don't believe there are any Test Cases though which could be an issue. -Scott Ben Alex wrote: 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:
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
Re: [Acegisecurity-developer] Reducing the number of filters needed in web.xml
Carlos Sanchez wrote: About the syntax, I looked at map, that would suit here, but Spring application context don't allow beans as keys, maybe a lack of functionality? Just use a custom PropertyEditor that works at a String level. The PropertyEditor would identify name/value pairs, and create its own internal Map. The name part of the pair would be a filter bean name that could be looked up from the application context (sure, you lose XML validation of the beans being present, but it's tolerable compared with a more verbose and confusing syntax). The value part of the pair would be the filter mapping. The filter mapping syntax is one to consider. Most people seem to prefer Ant Paths, so this might be a more suitable default (perhaps the only option?) than regular expressions. Remember this new class will need to make the decision as to which filters to delegate to. Also, I'd vote for it going into net.sf.acegisecurity.util, where FilterToBeanProxy is located. What is the consensus? Cheers Ben --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ 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
To sum up, I'll create a class called net.sf.acegisecurity.FilterChain, with a property called filters. About the syntax, I looked at map, that would suit here, but Spring application context don't allow beans as keys, maybe a lack of functionality? If we use this one we lose validation, so another option could be: bean id=filterMapping abstract=true class=net.sf.acegisecurity.FilterMapping property name=mappingvalue/*/value/property /bean bean id=channelProcessingFilterMapping parent=filterMapping property name=filterref local=channelProcessingFilter//property /bean bean id=authenticationProcessingFilterMapping parent=filterMapping property name=filterref local=authenticationProcessingFilter//property /bean bean id=filterChain class=net.sf.acegisecurity.FilterChain property name=filters list ref local=channelProcessingFilterMapping/ ref local=authenticationProcessingFilterMapping/ /list /property /bean More verbose, sure, but allows validation and avoids parsing and it's unlikely to change from one app to another. If you are using XML you should avoid parsing text, that's the goal of XML. The problem is that Spring DTD is a bit verbose. On Mon, 24 Jan 2005 11:15:03 +1100, Ben Alex [EMAIL PROTECTED] wrote: bryan ( [EMAIL PROTECTED]) wrote: bean id=filterChain class=net.sf.acegisecurity.FilterChain property name=filters value channelProcessingFilter=/* authenticationProcessingFilter=/* basicProcessingFilter=/* sessionIntegrationFilter=/* securityEnforcementFilter=/* /value /property /bean +1, especially using the syntax shown above as it's nice and intuitive. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ 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
Ray Krueger wrote: I like the idea as well, my only question is (and I've been wondering this for a while), why do we target the class and not the bean name? init-param param-nametargetClass/param-name param-valuenet.sf.acegisecurity.FilterChain/param-value /init-param Instead of... init-param param-nametargetBean/param-name param-valuefilterChain/param-value /init-param There's no strong reason Ray. It's just most webapps will only have one instance of each class, so using class is a way of delivering better documentation of what the filter is actually doing. This particularly helps with support. Ben --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ 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
This idea looks good to me. Regards, Dmitriy. - Original Message - From: Carlos Sanchez [EMAIL PROTECTED] Date: Sunday, January 23, 2005 7:59 am Subject: [Acegisecurity-developer] Reducing the number of filters needed in web.xml Hi, I think this was already discussed but I wasn't able to find it. I'd like to reduce the number of filters in web.xml to just one, say filter filter-nameAcegi Filter/filter-name filter-classnet.sf.acegisecurity.util.FilterToBeanProxy/filter- class init-param param-nametargetClass/param-name param-valuenet.sf.acegisecurity.FilterChain/param-value /init-param /filter And configure the chain of filters in the application context, something like bean id=filterChain class=net.sf.acegisecurity.FilterChain property name=filters list ref local=channelProcessingFilter/ ref local=authenticationProcessingFilter/ ref local=basicProcessingFilter/ ref local=sessionIntegrationFilter/ ref local=securityEnforcementFilter/ /list /property property name=filterMappings list value/*/value value/*/value value/*/value value/*/value value/*/value /list /property/bean Any thoughts? Regards Carlos Sanchez A Coruña, Spain http://www.jroller.com/page/carlossg --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive ReportingTool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ 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
I think they're is a more elegant and intuitive way to do this. I also think this a good idea,it would be good to have a more elegant syntax though, perhaps you might also consider the following. snip -- And configure the chain of filters in the application context, something like bean id=filterChain class=net.sf.acegisecurity.FilterChain property name=filters value channelProcessingFilter=/* authenticationProcessingFilter=/* basicProcessingFilter=/* sessionIntegrationFilter=/* securityEnforcementFilter=/* /value /property /bean Best Regards Bryan Hunt On Sun, 23 Jan 2005 09:26:48 -0500, Dmitriy Kopylenko [EMAIL PROTECTED] wrote: This idea looks good to me. Regards, Dmitriy. - Original Message - From: Carlos Sanchez [EMAIL PROTECTED] Date: Sunday, January 23, 2005 7:59 am Subject: [Acegisecurity-developer] Reducing the number of filters needed in web.xml Hi, I think this was already discussed but I wasn't able to find it. I'd like to reduce the number of filters in web.xml to just one, say filter filter-nameAcegi Filter/filter-name filter-classnet.sf.acegisecurity.util.FilterToBeanProxy/filter- class init-param param-nametargetClass/param-name param-valuenet.sf.acegisecurity.FilterChain/param-value /init-param /filter And configure the chain of filters in the application context, something like bean id=filterChain class=net.sf.acegisecurity.FilterChain property name=filters list ref local=channelProcessingFilter/ ref local=authenticationProcessingFilter/ ref local=basicProcessingFilter/ ref local=sessionIntegrationFilter/ ref local=securityEnforcementFilter/ /list /property property name=filterMappings list value/*/value value/*/value value/*/value value/*/value value/*/value /list /property/bean Any thoughts? Regards Carlos Sanchez A Coruña, Spain http://www.jroller.com/page/carlossg --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive ReportingTool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ 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
bryan ( [EMAIL PROTECTED]) wrote: bean id=filterChain class=net.sf.acegisecurity.FilterChain property name=filters value channelProcessingFilter=/* authenticationProcessingFilter=/* basicProcessingFilter=/* sessionIntegrationFilter=/* securityEnforcementFilter=/* /value /property /bean +1, especially using the syntax shown above as it's nice and intuitive. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ 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
+1 to this -Scott Shishir K. Singh wrote: +1 to it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of bryan ( [EMAIL PROTECTED]) Sent: Sunday, January 23, 2005 11:52 AM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Reducing the number of filters needed in web.xml I think they're is a more elegant and intuitive way to do this. I also think this a good idea,it would be good to have a more elegant syntax though, perhaps you might also consider the following. snip -- And configure the chain of filters in the application context, something like bean id=filterChain class=net.sf.acegisecurity.FilterChain property name=filters value channelProcessingFilter=/* authenticationProcessingFilter=/* basicProcessingFilter=/* sessionIntegrationFilter=/* securityEnforcementFilter=/* /value /property /bean Best Regards Bryan Hunt On Sun, 23 Jan 2005 09:26:48 -0500, Dmitriy Kopylenko [EMAIL PROTECTED] wrote: This idea looks good to me. Regards, Dmitriy. - Original Message - From: Carlos Sanchez [EMAIL PROTECTED] Date: Sunday, January 23, 2005 7:59 am Subject: [Acegisecurity-developer] Reducing the number of filters needed in web.xml Hi, I think this was already discussed but I wasn't able to find it. I'd like to reduce the number of filters in web.xml to just one, say filter filter-nameAcegi Filter/filter-name filter-classnet.sf.acegisecurity.util.FilterToBeanProxy/filter- class init-param param-nametargetClass/param-name param-valuenet.sf.acegisecurity.FilterChain/param-value /init-param /filter And configure the chain of filters in the application context, something like bean id=filterChain class=net.sf.acegisecurity.FilterChain property name=filters list ref local=channelProcessingFilter/ ref local=authenticationProcessingFilter/ ref local=basicProcessingFilter/ ref local=sessionIntegrationFilter/ ref local=securityEnforcementFilter/ /list /property property name=filterMappings list value/*/value value/*/value value/*/value value/*/value value/*/value /list /property/bean Any thoughts? Regards Carlos Sanchez A Coruña, Spain http://www.jroller.com/page/carlossg --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive ReportingTool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Re: [Acegisecurity-developer] Reducing the number of filters needed in web.xml
+1 regards, -- Ricardo Ben Alex wrote: bryan ( [EMAIL PROTECTED]) wrote: bean id=filterChain class=net.sf.acegisecurity.FilterChain property name=filters value channelProcessingFilter=/* authenticationProcessingFilter=/* basicProcessingFilter=/* sessionIntegrationFilter=/* securityEnforcementFilter=/* /value /property /bean +1, especially using the syntax shown above as it's nice and intuitive. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ 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
I like the idea as well, my only question is (and I've been wondering this for a while), why do we target the class and not the bean name? init-param param-nametargetClass/param-name param-valuenet.sf.acegisecurity.FilterChain/param-value /init-param Instead of... init-param param-nametargetBean/param-name param-valuefilterChain/param-value /init-param On Sun, 23 Jan 2005 23:57:55 -0200, Ricardo Marin Matinata [EMAIL PROTECTED] wrote: +1 regards, -- Ricardo Ben Alex wrote: bryan ( [EMAIL PROTECTED]) wrote: bean id=filterChain class=net.sf.acegisecurity.FilterChain property name=filters value channelProcessingFilter=/* authenticationProcessingFilter=/* basicProcessingFilter=/* sessionIntegrationFilter=/* securityEnforcementFilter=/* /value /property /bean +1, especially using the syntax shown above as it's nice and intuitive. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
