> 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.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.