Hi Wesley
Thanks for the contribution.
Wesley Hall wrote:
I've committed this one, minus the UsernameNotFoundException (because it gets re-thrown by DaoAuthenticationProvider in a BadCredentialsException).Hi Ben,
I have made some changes to the attached classes...
AbstractProcessingFilter -----------------------------
authenticationServiceFailureUrl - AuthenticationServiceException authenticationCredentialCheckFailureUrl - BadCredentialsException authenticationDisabledFailureUrl - DisabledException authenticationLockedFailureUrl - LockedException authenticationProxyUntrustedFailureUrl - ProxyUntrustedException authenticationUsernameNotFoundFailureUrl - UsernameNotFoundException
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.
AuthenicationException -------------------------------
I have added an 'Authentication' attribute to the exception.
I've also committed this one.
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?ProviderManager -------------------------------
I have wrapped the calls to provider.authenticate in a try block that catchs AuthenticationException. This is so I can intercept the exception to populate the authentication object into the Exception, it is then rethrown. Also the final ProviderNotFoundException is created first so that the authentication may be set before the instance is thrown.
An implication of this approch is that custom implementations of AuthenticationManager will need to do their own work to populate the exception with the authentication object. I did not see this as a major problem as there seems to be little reason to create a custom AuthenticationManager rather than a AuthenticationProvider. An alternative might be to make AuthenticationManager an abstract class and use the template pattern to move the authentication population up into AuthenticationManager but this change was too invasive for my taste.
I have performed some tests of these changes by integrating them into my project and doing some functional tests. Everything seems to work ok for me.
Perhaps you would like to integrate these changes into the next version of acegi. If not, perhaps somebody on the list has similar requirements to me and would like to include these changes in their project.
In either case, please accept these changes as is and distributed under the apache license as the rest of the acegi code.
Thanks again for your contributions and feedback, Wesley.
Best regards Ben
------------------------------------------------------- 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
