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