users@glassfish.java.net

Re: Obtaining LoginException

From: <Jan.Luehe_at_Sun.COM>
Date: Wed, 08 Aug 2007 11:45:33 -0700

Hi Joe,

Shevland, Joe wrote:

>>an RFE might be in place. Any information (e.g., exception)
>>related to the authentication failure could be stored in the
>>session that was established during FORM authentication (to
>>store the original request URL to which the user would be
>>redirected following a successful authentication), so that
>>the form-error-page could retrieve it from there.
>>
>>However, in GlassFish, there is no exception thrown or
>>propagated in the case of any FORM authentication failure (I
>>think this is on purpose, because you don't want to disclose
>>to a potential attacker too many details as to why they could
>>not be authenticated), so I'm not sure how useful the RFE
>>would be in the end.
>>
>>
>
>I'm not advocating presenting the exception back to the user/client, but
>somewhere the developer can make a call on it. As it's a requirement for
>me at the moment to provide some form of meaningful feedback based on
>the authentication failure, I'm going to have to investigate creating a
>homegrown authentication mechanism for the web application/s and calling
>my custom realm/module directly I guess, and throw out container
>integrated security.
>
>I'm very surprised that being able to check the cause of the failure for
>authentication problems isn't possible, even for the developer to make
>the call as to whether something as braindead as "Login failed" is
>presented when in fact the authentication database is not available, the
>account has expired, the password needs a reset etc.
>
>

As I mentioned earlier, the only solution I can imagine for this
to work would be to store any error information regarding the
authentication failure in the HTTP session that was established
by the container to store the original request URL (which the
user would be redirected to should authentication succeed).

The form login's error page, which will have access to this
session, could then retrieve the error information from there
and display it properly.

Of course, for this to be portable, the servlet spec would need
to define the name of the session attribute where the container
would store the authentication error (we could reuse the name
of the request attribute "javax.servlet.error.exception" for this
purpose).


Jan