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