Hi Magnus, Magnus Johansson schrieb: > Hi > > Thanks for your answer... it all makes sense except for one small detail > > If I try to follow the code this is my understanding: > > 1. SlingAuthenticator calls my AuthenticationHandler.authenticate > 2. AuthenticationHandler.authenticate return null as no user is currently > logged in > 3. SlingAuthenticator will now call SlingAuthenticator.getAnonymousSession > 4. SlingAuthenticator.getAnonymousSession will redirect to LoginServlet
Oops, this is probably not correct and getAnonymousSession should probably call login directly... > 5. LoginServlet will call AuthenticationHandler.login (via > SlingAuthenticator) > > In step 5 my AuthenticationHandler can not get the original request uri that > was requested > by the user at 1 because of the redirect in step 4. Correct ... > > One solution/hack in my AuthenticationHandler would be in step 2 to return > incorrect > credentials instead of returning null. This would force SlingAuthenticator > to call handleLoginFailure and > thus login on my AuthenticationHandler. However, this would mean that I > "loose" the built-in > support for anonymous users. > > The other solution would be for step 4 to actually call > AuthenticationHandler.login directly (without > a redirect). This might of course have some unwanted side-effects that I > haven't thought of. I would assume, that this is probably an oversight of mine when I refactored the login mechanism adding the AuthenticaitonService.login method. I created SLING-1032 [1] to track this and fix it by calling login if anonymous access is not allowed. And fixed in the engine bundle in Rev. 791120. IIRC we keep the LoginServlet for backwards compatibility and for an easy entry point into generic system login. As such the LoginServlet should be accessed from the outside and not from within. Regards Felix [1] https://issues.apache.org/jira/browse/SLING-1032
