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