All done, please test. Ian On 28 Jul 2010, at 16:47, Ian Boston wrote:
> Ok fixed SLING-1588, > Looking at adding config to allow Form or no Form when the token expires. > Ian > > On 28 Jul 2010, at 16:15, Mike Moulton wrote: > >> Thank you for the prompt responses. I have created SLING-1614 [1] to address >> this issue. >> >> -- Mike >> >> [1] https://issues.apache.org/jira/browse/SLING-1614 >> >> >> On Jul 28, 2010, at 7:41 AM, Ian Boston wrote: >> >>> >>> On 28 Jul 2010, at 15:08, Justin Edelson wrote: >>> >>>> On 7/28/10 4:12 AM, Ian Boston wrote: >>>>> >>>>> On 28 Jul 2010, at 08:02, Felix Meschberger wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I would say, this is a new bug. IMO a timed-out cookie should actually >>>>>> be deleted by the Form authentication handler and the request should >>>>>> proceed as if it would not be authenticated. >>>>>> >>>>>> Another solution would be to recognize the timeout and force login >>>>>> again; which would also be the task of the Form authentication handler. >>>>>> >>>>>> What would be the right thing to do ? >>>>> >>>>> An invalid/expired or missing cookie should result in an anonymous user >>>>> session into JCR. >>>>> If the resource requested is protected it should result in a 401 and the >>>>> 401 handler for the application should encourage the user to log back in. >>>>> (might even display a login box depending on app) >>>>> >>>>> From the description the invalid cookie is resulting in some undetermined >>>>> state that makes no sense as the user is not returning to the anon state. >>>>> (not certain what their state is). >>>>> >>>>>> Should this be configurable ? >>>>> >>>>> Yes, but bear in mind, once the cookie is invalid, which >>>>> AuthenticationHandlers should be used ? In our use of Sling we >>>>> potentially have many AH's and the user may have logged out because they >>>>> want to login with another method. I think the 401/403/404 handler >>>>> approach allows that configuration. >>>>> >>>>> Happy to fix verify and fix the cookie issue later today, I think it >>>>> might have been a bug on my part. >>>>> Ian >>>>> >>>> Ian- >>>> While you're in there, you might also want to look at SLING-1588. It >>>> looks like that issue and this one might be related. I'm sorry to say >>>> that I didn't have a lot of time to look into SLING-1588 (especially >>>> because I needed to use the workaround for other reasons), but what >>>> little I was able to see what that it had something to do with invalid >>>> credentials resulting in a redirect to the login page. >>> >>> >>> Will do >>> Ian >>> >>>> >>>> Justin >>>> >>>>> >>>>>> >>>>>> Regards >>>>>> Felix >>>>>> >>>>>> On 27.07.2010 23:42, Mike Moulton wrote: >>>>>>> I'm experiencing a potential problem with formauth in the latest trunk >>>>>>> of sling (r979875) that I wanted to check to see if this is now the >>>>>>> intended behavior with all the recent auth changes, or is a newly >>>>>>> introduced bug. >>>>>>> >>>>>>> Here is my scenario: >>>>>>> >>>>>>> - Start up the standalone sling. >>>>>>> - Install the form auth bundle. >>>>>>> - Goto: http://localhost:8080/index.html - page should render >>>>>>> - Goto: http://localhost:8080/system/sling/form/login - login >>>>>>> - Goto: http://localhost:8080/index.html - page should still render >>>>>>> - Wait for session cookie to timeout (I lowered the timeout to 1 min >>>>>>> for my testing) >>>>>>> - Refresh: http://localhost:8080/index.html - page will redirect to >>>>>>> login form >>>>>>> >>>>>>> Once the cookie times out I can no longer get to any resource >>>>>>> (regardless of ACL's on the resource) without either logging back in or >>>>>>> deleting the cookie from my browser. This effectively locks me out of >>>>>>> the repo and prevents the user from returning to an anonymous user >>>>>>> state. >>>>>>> >>>>>>> Is this the intended behavior? >>>>> >>>> >>> >> >
