+1
On Apr 6, 2009, at 1:52 PM, Les Hazlewood wrote:
I think I like the latter only because it matches exactly what was
there previously. So, just changing jsec -> ki should be enough.
That ok?
On Mon, Apr 6, 2009 at 1:51 PM, Les Hazlewood
<[email protected]> wrote:
Should it be kiLoginException or kiLoginFailure ? the latter is
even shorter, and could also convey that maybe it failed not due to
an exception, but perhaps something else...
On Mon, Apr 6, 2009 at 1:49 PM, Les Hazlewood
<[email protected]> wrote:
Fair enough. I'll change it now, and if anyone else feels strongly
otherwise, please append to this thread.
Thanks,
Les
On Mon, Apr 6, 2009 at 1:43 PM, Jeremy Haile <[email protected]>
wrote:
But isn't this why the property exists on the filter - to override
it in one place if you don't like the default?
You can override it, but I don't think we should have the default be
a property that users feel like they have to override because the
name is so verbose and annoying to use =) I think the default
should be nice and simple, and we should have our simple webapp
example use that property. If the user wants to override it for
some reason, or in the rare case (probably never) that it conflicts
with some other request attribute, they can easily override it.
My 2 cents...
On Mon, Apr 6, 2009 at 1:26 PM, Jeremy Haile <[email protected]>
wrote:
I understand why you did this - it's a cleaner namespace, etc. but
it makes it a pain in the butt to reference in code. I'm trying to
find a shorter attribute that is still relatively safe but isn't so
dang long.
As to why it would be used in a JSP - see my simple example earlier
in this thread.
On Apr 6, 2009, at 1:16 PM, Les Hazlewood wrote:
To further explain my thoughts: by having a prefix 'ki.', instead
of just 'ki', I'm being explicit that the attribute is something
ki set, whereas 'kiAuthenticationException' might imply that the
exception is an AuthenticationException concrete subclass instance
in the API. But, because end-users can subclass the exception
hierarchy, it might not be a ki exception directly. It could also
be an application-specific exception.
A very minor distinction, sure, but that was my reasoning at least.
On Mon, Apr 6, 2009 at 1:09 PM, Les Hazlewood
<[email protected]> wrote:
Because its not the AuthenticationException itself - just the
class name.
Just 'kiLoginException" would imply the following would be possible:
AuthenticationException exception =
(AuthenticationException)request.getAttribute("kiLoginException");
which is not the case.
Just out of curiosity, why would a JSP reference this value? And
even if they did, isn't that the purpose of the setter method to
override the default in case the end-user didn't like to type that?
On Mon, Apr 6, 2009 at 1:03 PM, Jeremy Haile <[email protected]>
wrote:
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
