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