[Acegisecurity-developer] Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security
Juergen Hoeller wrote: I've also taken the two convenience methods in Acegi's StringSplitUtils class and moved them over to Spring's StringUtils. In the course of this, I've transformed the "splitEachArrayElementAndCreateMap" method into "splitArrayElementsIntoProperties", essentially returning a Properties instance instead of a Map (since all we ever get back is String-String pairs). My goal for Spring 1.2 final is that the Acegi util package should only contain Acegi-specific utilities, no general utility stuff anymore. With the addition of DelegatingFilterProxy and the String split methods to core Spring, we should be pretty there... An Acegi release 0.9 alongside Spring 1.2 final would be appropriate, I guess. Opinions welcome, of course :-) Ben, when do you plan to go to 1.0 RC with Acegi? Maybe alongside Spring 1.3 RC, which is currently scheduled for right before JavaOne? I think that would be a great message, to show that Acegi is fully active and supported. (BTW, FilterChainProxy in net.sf.acegisecurity.util has dependencies on the net.sf.acegisecurity and net.sf.acegisecurity.intercept.web packages, so arguably doesn't belong in the low-level util package...) Hi Juergen All of this sounds great. Our general release plan at this stage is: - Release 0.8.2. To release ASAP. It will require Spring 1.2-RC2, and fix the current 0.8.1 to 1.2-RC2 incompatibility. - Release 0.9.0. Refactor to use a dedicated SecurityContext ThreadLocal and also Spring 1.2-Final util package migration. - Release 1.0.0-RC1. A Spring 1.3 pre-JavaOne release sounds like a good target. In terms of your other email's suggestion to use a SecurityContext ThreadLocal instead of ContextHolder, I've given this some more thought and we can do this and still offer a clean migration path for 99% of existing ContextHolder users. Whilst I know some people (myself included) have found ContextHolder's general-purpose approach useful, it seems more important overall to achieve standardization with Spring Core in the ThreadLocal approach, and as such it seems worthwhile refactoring to SecurityContext. Any comments from the community are welcome. Cheers Ben --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ 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] Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security
On Wed, 20 Apr 2005 23:19:05 +1000, Ben Alex wrote > In terms of your other email's suggestion to use a SecurityContext > ThreadLocal instead of ContextHolder, I've given this some more > thought and we can do this and still offer a clean migration path > for 99% of existing ContextHolder users. Whilst I know some people > (myself included) have found ContextHolder's general-purpose > approach useful, it seems more important overall to achieve > standardization with Spring Core in the ThreadLocal approach, and as > such it seems worthwhile refactoring to SecurityContext. I think the nomenclature of SecurityContext does make more sense, but then again I don't need the general approach of ContextHolder. Just my 2c. Scott --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Acegi Security facade
Hello! I started using Acegi 2 days ago, and now I have a fully working simple authentication / authorization without writing any code or referencing any Acegi classes - this is very impressive! Previously we implemented our own 'security' (authentication) for another appication, which I believe would take me at least 4 days to incorporate into new project... I am done with complements, now I will get on with critique :). Acegi Facade. IMH Acegi needs a facade bean, which would administer wiring and setting up default behaviour. For beginners it would be great if you could just add 1 bean to your application's spring context, which holds inmemory user/password, and URL to role mappings and basic authentication. This way you can get your application running with Acegi in 15 minutes, and build on from there. As a matter of fact even if you are not a novice, you would probably want to start there as well... Advanced users still should be able to substitute default behaviour, by changing default configuration or implementation ["Simplifying Acegi Configuration" Craig Walls]. Implementation would most likely include pre-packaging default configuration and wiring in the jar. Thanks a lot.Vadim Pesochinskiy[EMAIL PROTECTED]__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Acegisecurity-developer] Acegi Security facade
Hello! I started using Acegi 2 days ago, and now I have a fully working simple authentication / authorization without writing any code or referencing any Acegi classes - this is very impressive! Previously we implemented our own 'security' (authentication) for another appication, which I believe would take me at least 4 days to incorporate into new project... I am done with complements, now I will get on with critique :). Acegi Facade. IMH Acegi needs a facade bean, which would administer wiring and setting up default behaviour. For beginners it would be great if you could just add 1 bean to your application's spring context, which holds inmemory user/password, and URL to role mappings and basic authentication. This way you can get your application running with Acegi in 15 minutes, and build on from there. As a matter of fact even if you are not a novice, you would probably want to start there as well... Advanced users still should be able to substitute default behaviour, by changing default configuration or implementation ["Simplifying Acegi Configuration" Craig Walls]. Implementation would most likely include pre-packaging default configuration and wiring in the jar. Thanks a lot.Vadim Pesochinskiy[EMAIL PROTECTED]__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Acegisecurity-developer] Acegi Security - new release 0.8.2
Dear Spring Community I'm pleased to announce that Acegi Security release 0.8.2 is now available. This release fixes a number of non-critical bugs, resolves an incompatibility with Spring 1.2-RC2 refactorings, updates JAR dependencies to match Spring 1.2-RC2, and refactors AbstractProcessingFilter exception mappings. As per the Apache APR project versioning guidelines, this is a minor release. Users of release 0.8.0 or 0.8.1 should be able to simply drop the new 0.8.2 JARs into their applications, although please be aware: 1. Spring 1.2-RC2 (or above, such as a CVS snapshot) is the minimum requirement for Acegi Security 0.8.2 2. Users of AbstractProcessingFilter (typically AuthenticationProcessingFilter) must modify their exception setters as per http://acegisecurity.sourceforge.net/multiproject/acegi-security/apidocs/net/sf/acegisecurity/ui/AbstractProcessingFilter.html Please note that Acegi Security releases prior to 0.8.2 will not operate with Spring 1.2-RC2. You will need to use the latest Acegi Security release (0.8.2) if you wish to operate with Spring 1.2-RC2. For Maven users, Acegi Security's latest JARs are now available from http://acegisecurity.sourceforge.net/maven/acegisecurity/jars. Release 0.8.2 will be added to iBiblio shortly. Please visit http://acegisecurity.sourceforge.net to learn more about Acegi Security's features, browse online documentation, or download the latest release. We hope you find this new release useful in your projects. Cheers Ben --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ 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] Acegi Security facade
Vadim Pesochinskiy wrote: IMH Acegi needs a facade bean, which would administer wiring and setting up default behaviour. We try to use sensible defaults (implemented in the Java classes) to minimise XML where possible. A variety of approaches are available to further reduce XML configuration: - Use a BeanPostProcessor - Make beans BeanFactoryAware, using DefaultListableBeanFactory to find likely collaborators and wire them - Use autowiring and inner beans more often - Use abstract beans as per Craig Walls' approach I actually prefer Craig's approach. Abstract beans are a standard Spring capability, and people who invest time in learning it receive benefits beyond Acegi Security. I believe the other approaches obfuscate the configuration source, which will increase difficulty when customising configuration or troubleshooting. However, I invite people who wish to write contributions that adopt these alternative approaches to submit them for inclusion in the project. Cheers Ben --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ 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] Acegi Security facade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Ben Alex > Sent: Wednesday, April 20, 2005 1:04 PM > To: acegisecurity-developer@lists.sourceforge.net > Subject: Re: [Acegisecurity-developer] Acegi Security facade > > Vadim Pesochinskiy wrote: > > > IMH Acegi needs a facade bean, which would administer wiring and > > setting up default behaviour. > > > We try to use sensible defaults (implemented in the Java > classes) to minimise XML where possible. > > A variety of approaches are available to further reduce XML > configuration: > > - Use a BeanPostProcessor > - Make beans BeanFactoryAware, using > DefaultListableBeanFactory to find likely collaborators and wire > them - Use autowiring and inner beans more often > - Use abstract beans as per Craig Walls' approach > > I actually prefer Craig's approach. Abstract beans are a > standard Spring capability, and people who invest time in > learning it receive benefits beyond Acegi Security. I believe > the other approaches obfuscate the configuration source, > which will increase difficulty when customising configuration > or troubleshooting. However, I invite people who wish to > write contributions that adopt these alternative approaches > to submit them for inclusion in the project. +1 on the use of the Abstract Bean definitions. Those definitely make things easier. Perhaps it would help to ship a XML config wired up completely for replacement of the default web.xml facilities? That way, for users wishing to merely access a drop-in replacement for web.xml security, there's a preconfigured XML in the jar ready to go. Of course, they can override the bean definition(s) as they see fit. But this would lower the bar for those that might feel Acegi requires too much configuration. Seth -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQmbuPymbBUsLVvsCEQLvCgCfTriT4bghyQIfjkwTk034Ist9TL0Aniob em0TIEEJCX8OHrI7u5WRm90Z =rrVL -END PGP SIGNATURE- --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] AfterInvocationManager and Provider
Just a thought. The AfterInvocationProvider class provides a supports(Class) method that checks whether an implementation supports the current secure object invocation or not. Wouldn't make it sense to add another method supportsReturnedObject(Class) to check if the implementation actually supports the returned object instance? This feature could be used by the AfterInvocationProviderManager to apply only "matching" AfterInvocationProviders. Otherwise you have to include this check in your decide() methods all the time. --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
