Ben, Thanks for taking the time to respond. (Comments below)
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Ben Alex > Sent: 20 July 2004 04:02 > To: [EMAIL PROTECTED] > Subject: Re: [Acegisecurity-developer] Suggestions for changes to > AbstractProcessingFilter > > > Hi Wesley > > Thanks for the suggestions. Comments below. > > Wesley Hall wrote: > > >Hello all, > > > >I have a couple of suggestions for changes to > AbstractProcessingFilter. I am > >not sure on process for submitting patches but I am happy to make these > >changes myself if somebody would care to provide this information. > > > >My first suggestion is to provide alternate failure URLs for the > different > >failure reasons. These URLs shouldnt need to be madatory as the > system could > >default to the mandatory failure URL. > > > >I have looked at the code for this class and it seems that the system > >catches an AuthenticatationException and if this is caught redirects the > >user to the specified failure URL. If this catch block was > extended to catch > >the relevant AuthenticationException subtypes the functionality could be > >easily extended to redirect to different URLs on different events if > >required by the developer. If there is no URL configured for the > particular > >exception type then the system should default to redirecting to > the existing > >failure URL. > > > > > Most Acegi Security implementations use SecurityEnforcementFilter. It is > that class which distinguishes between authorization vs authentication > failures in lower-down classes, providing a 403 in the event of an > AccessDeniedException and a redirect to the AuthenticationEntryPoint in > the event of an AuthenticationException. The > AuthenticationProcessingFilter logic is only executed when an actual > authentication attempt is made (eg a BASIC authentication header is > detected, a form-based login is submitted etc) so it is unlikely it > would ever see say an AccessDeniedException. So if you'd like > alternative handling of AccessDeniedExceptions, it might be more helpful > to put it within the SecurityEnforcementFilter. The functionality I am suggesting relates purely to when an authentication attempt is made. I have written an AuthenticationProvider implementation as my requirements go slightly beyond the features provided within the DaoProvider. My implementation of the authenticate method throws different AuthenticationException subtypes (currently only subtypes provided by acegi such as DisabledException). It would be useful for me to redirect the user to different URLs depending on which exception type was thrown by the provider. My suggestion to provide this feature without breaking existing functionality is to add some extra properties to AbstractProcessingFilter (which currently holds the generic 'authenticationFailureUrl') to include optional URLs to redirect the user in the event of a DisabledException or LockedException (for instance). Extend the catch block (that currently catches the AuthenticationException superclass) to catch the main subclasses and in each catch block check if the URL property for that type of failure is null. If it is null, continue with existing behaviour and forward to the mandatory authenticationFailureUrl, but if it is not null, forward to this specific URL instead. The definition for the bean in the spring configuration file becomes... <bean id="authenticationProcessingFilter" class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter"> <property name="authenticationManager"><ref bean="authenticationManager"/></property> <property name="authenticationFailureUrl"><value>/logon.jsp?error=1</value></property> <property name="accountDisabledUrl"><value>/logon.jsp?error=2</value></property> <property name="accountLockedUrl"><value>/logon.jsp?error=3</value></property> <property name="defaultTargetUrl"><value>/secure/index.html</value></property> <property name="filterProcessesUrl"><value>/j_acegi_security_check</value></property> </bean> ...for example. Here the system provides the error page with the parameter error=2 for DisabledException and error=3 for LockedException and defaults to error=1 for all other exceptions. As the new properties are optional, and the system defaults to the existing mandatory url, backward compatibility is maintained. I may have some time this evening to make these changes, I will need them for my project anyway, I will of course provide them back to you and you can decide whether there is merit in including them in a future version. As I am not sure of the preferred format to supply patches I will just email the altered files to this mailing list. Ideally I would like to take a branch of the current head to make these changes on, but I assume sourceforge doesnt have seperate permissions for branch creation and committing to the head and I understand that you may not want to give commit access to anyone that comes along and asks for it. > >The second suggestion is that, upon authentication failure, the > system could > >place the authentication object (that failed) into the session. If the > >failure pages are dynamic then the failure pages could perform some > >application specific logic to display even more information to > the user. For > >example... "Authentication has failed. Your account was disabled by > >'joe_superuser' at 19/07/04 at 14:22". > > > > > > > A challenge with this would be to obtain a "failed" Authentication > object. Subclasses of AuthenticationProcessingFilter implement a "public > abstract Authentication attemptAuthentication(HttpServletRequest)" > method which is responsible for returning the successful Authentication > or throwing a relevant exception. Of course there are ways to do it > (mandate the attempted Authentication inside the returned exception, > have subclasses place the attempted Authentication in a well-known > location etc) but it would require subclass-level code changes. Your > more informative error message requirement can presently be accommodated > via the use of more detailed exception messages. The exception causing a > failed authentication is put into the HttpSession against the > ACEGI_SECURITY_LAST_EXCEPTION_KEY attribute. So if you wanted the sort > of details provided in your example, you could modify your > AuthenticationManager (or more likely, a custom > DaoAuthenticationProvider subclass) to provide this extra level of > information. A thought... why not add an attribute of type 'Authentication' to the AuthenticationException class. This would allow the system to provide the "failed" Authentication with the AuthenticationException. This seems like a fairly natural design move as the first thought after catching an AuthenicationException might be "so which 'Authentication' failed?". Again, happy to make this change. 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
