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 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.
HTH
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
