Oops - accidentally replied to an incorrect thread. Meant to post here:
What about kiLoginException? I like short and sweet since this will
likely be referenced directly from JSPs
On Apr 6, 2009, at 12:57 PM, Les Hazlewood wrote:
P.S. That was my best initial solution to the problem - by storing
a fully qualified exception name of the failure exception. Maybe
that's good enough, but if there is a more elegant solution, I'm all
ears!
On Mon, Apr 6, 2009 at 12:52 PM, Kalle Korhonen <[email protected]
> wrote:
Thanks Jeremy, that's exactly what I was after. With that info I
don't need to re-try the login.
Kalle
On Mon, Apr 6, 2009 at 9:38 AM, Jeremy Haile <[email protected]>
wrote:
If you are using the FormAuthenticationFilter (the default), you can
also put some logic in your view layer to display the error
message. Ki automatically adds the fully qualified class name of
the exception that was thrown as a request attribute that you can
key off of. The request attribute is based on the
"failureKeyAttribute" property of the filter, so you can adjust in
your ini by setting "authc.failureKeyAttribute=myAttribute" The
default attribute name is "jsecLoginFailure".
By default it is set to the fully qualified classname of the
exception that was thrown during authentication. This would allow
you to do something like (simple JSP example):
<c:if test="${jsecLoginFailure eq
'org.jsecurity.authc.IncorrectCredentialsException'}">
<span class="errors">The password you entered is incorrect.</span>
</c:if>
To do something more custom when authentication fails (but still
using the built-in filter), you could always extend
FormAuthenticationFilter and override the setFailureAttribute(...)
method or onLoginFailure(...) method.
Jeremy
On Apr 6, 2009, at 12:23 PM, Kalle Korhonen wrote:
(Had accidentally sent to dev list, moving to user list).
On Mon, Apr 6, 2009 at 6:07 AM, Jeremy Haile <[email protected]>
wrote:
How authentication failures are displayed to the user is generally
application specific. Usually applications catch
AuthenticationException or some of its subclasses if more granular
reporting is required. They then translate those exceptions into a
validation message and display it to the user. Also, for security
reasons, it's generally not a good idea to tell the user whether
they entered a non-existant username or an incorrect password.
Thanks for reply, Jeremy. Yes, that's obvious.
The simplest example may look like this:
try {
subject.login(...);
} catch (AuthenticationException e) {
// Add something to the request to communicate the
login failure to the user
}
You could add additional catch blocks above the
AuthenticationException to catch different subclass exceptions and
give more specific error messages.
Exactly - that's what I meant when I said "handle login myself".
Exception handling is straight-forwarded in this case. If it wasn't
clear from my previous example, the question was: "How does the
application obtain the failure reason if Ki filtered is configured
to run before the application filters and handles the
authentication"? From what I gathered, the answer is either "not
meant to do so" or "up to you to implement", in which case an
exception specific error-page may be the best solution.
To obtain the originally requested URL from Ki, call
WebUtils.getSavedRequest(...) which will give you back a
SavedRequest object describing the original request. This can be
used to redirect after login.
If you do not want Ki to do the authentication for you, but would
rather execute it in your web framework, you can change the "authc"
filter to pass-thru requests to your web framework. In this case,
Ki assumes that you will handle the authentication yourself which
sounds like the behavior you are after. To get this to work, add the
Ah, missed WebUtils. Yeah, if you read my description again, you'll
see that I'd rather not handle the login myself but in that case
the problem is how do I let the application know in that case why
the authentication failed. It's not simply a choice between filter
handling authentication or the application handling it. If it's
handled in the application, the request may needs to pass through
several other filters, but if it's its handled in the
authentication filter the control has not yet been passed to the
lower layers. Sounds like my solution (let framework handle the
success case, but allow failure case to go through to the
application layer) has some advantages.
Kalle
On Apr 6, 2009, at 2:04 AM, Kalle Korhonen wrote:
Is there a standard/recommend way in JSecurity/Ki to make the
reason for an
authentication failure available to the application? Similarly to
CMA, if Ki
is configured to run before the application servlet/filter, there's
no
direct way to tell the application why an authentication try
failed. Is the
recommended mechanism in this case to try to use a standard
"<error-page><exception-type>" element in web.xml or something
else? The
other way around, if I create a login form and handle the
authentication in
it myself (by calling SecurityUtils.getSubject().login() ) is there
a way to
obtain the "originally requested url" from Ki that the security
filter
intercepted, then redirected to login page?
Currently I implemented this so that a login form that *could*
handle login,
but a success case is directly handled by Ki. In a failure case, Ki
let's
the request through and I just re-try the authentication to get the
failure
reason. This is a little hackish and results in an unnecessary
authentication try in a failure case, but works surprisingly well
for me as
it allows me to use the "native" error message mechanisms of my web
application framework.
Kalle
