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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
