Ben, Comments below...
> > > I've committed this one, minus the UsernameNotFoundException (because it > gets re-thrown by DaoAuthenticationProvider in a BadCredentialsException). > > If people need to support additional application-specific (rather than > Acegi Security-specific) exceptions, we could provide a hook method that > subclasses can optionally override which returns a target URL. > Alternatively, people can perform additional conditional processing in > the target URL servlet/filter/page etc based on HttpSession's > ACEGI_SECURITY_LAST_EXCEPTION_KEY attribute. Yes, I wasnt too sure about the distiction between UsernameNotFoundException and BadCredentialsException, I probably should have looked into this a little more deeply, but the assumption I made was that the former meant an incorrect username and the latter an incorrect password. On the second point, I did spend a little time considering how to handle custom subclasses of AuthenticationException and I considered implementing both the hook method you describe and also a 'AuthenticationFailureUrlResolver' that could be plugged in in the application context XML file. However, I got a little nervous about the code that would be required to do the dynamic type checking on the custom exceptions. J2EE classloading is not known for its simplicity and I found it difficult to think my way through all the end-cases. I eventually came to the same conclusion as you have, that the end-user can use the exception stored in the session to perform more specific logic and that it may be better to wait until there is a specific requirement for the core ACEGI classes to handle these specific exception types. The current types seem pretty comprehensive anway. > > > I haven't committed this one because I believe re-throwing the exception > loses the all-important lower-down stack trace. I believe it's probably > better to change individual AuthenticationProviders to use the enhanced > AuthenticationException subclasses properly, rather than relying on > ProviderManager to do it for them. Do you agree, or is there some other > issue that I haven't considered? This would actually be my preference too. I dont think the stack trace will be affected unless a new exception is created, but I would have liked to set the Authentication object in an overloaded constructor. The problem is that it seemed that in some cases the Authenication instance wasnt available. The advantage of intercepting it in the ProviderManager is that it seems to be a central location where there is access to the Authenication instance, so no matter how the user decides to implement their custom AuthenicationProvider or Dao the Authenication object will always be available when it counts. I guess there are pros and cons of both approches, but I didnt want to dive in and start making very invasive changes and given that the ProviderManager interception represented the least invasive change, I eventually opted for this route. > Thanks again for your contributions and feedback, Wesley. You are very welcome, and thank you for your work on creating a wonderful security framework, and finally freeing me and many other developers for the inflexible nightmare that is J2EE container-managed authentication ;o) Regards Wesley Hall ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
