shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Haile <>
Subject Re: Obtaining reason for authentication failure / exception handling
Date Mon, 06 Apr 2009 17:03:47 GMT
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 < 
> > 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 <>  
> 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 <>  
>> 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

View raw message