shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: Obtaining reason for authentication failure / exception handling
Date Mon, 06 Apr 2009 17:51:10 GMT
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 <lhazlewood@apache.org> 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 <jhaile@fastmail.fm> 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 <jhaile@fastmail.fm> 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 <lhazlewood@apache.org>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 <jhaile@fastmail.fm>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 <
>>>>> kalle.o.korhonen@gmail.com> 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 <jhaile@fastmail.fm>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 <jhaile@fastmail.fm>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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>

Mime
View raw message