You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (Created) (JIRA)" <ji...@apache.org> on 2011/12/15 14:24:30 UTC
[jira] [Created] (SLING-2329) Fix redirect loop prevention of
SlingAuthenticator
Fix redirect loop prevention of SlingAuthenticator
--------------------------------------------------
Key: SLING-2329
URL: https://issues.apache.org/jira/browse/SLING-2329
Project: Sling
Issue Type: Bug
Components: Authentication
Affects Versions: Auth Core 1.0.6
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Fix For: Auth Core 1.1.0
According to comment [1] in SLING-1831 the SlingAuthenticator.doLogin method sends back a 401 status in case of a browser-based login loop. This (Rev. https://fisheye6.atlassian.com/changelog/sling?cs=1021641) changes the Rev. https://fisheye6.atlassian.com/changelog/sling?cs=1021309 fix which caused a 403/FORBIDDEN to be sent back on login loop.
Basically, this is wrong.
The correct thing to do is:
* If HTTP Basic credentials are provided, the browser will only let them go if a 401 status is received. This led to the Rev. 1021641 fix.
* If no credentials are provided, the AuthenticationHandler would have been responsible for preventing such a loop. The Sling Authenticator just acts as a safety net here. This led to the Rev. 1021309 fix.
The problem is, that both situations are actually valid and must be handled differently. Yet the correct way to handle the first situation is actually to implement the AuthenticationFeedbackHandler.authenticationFailed method in the HTTP Basic authentication handler: This method is called if authentication with credentials provided by an AuthenticationHandler are not valid. In the case of the HTTP Basic authentication handler, the Basic authentication credentials are invalid and the authenticationFailed method should thus send back a 401 response.
Then, for the second case, the original Rev. 1021309 situation can be recreated again by sending a 403 in a perceived loop. This works because in the case of invalid HTTP Basic credentials the authenticationFailed method has already been called to send back the 401. In any other case it must be assumed the authentication handler ran havoc and thus authentication must be terminated.
[1] https://issues.apache.org/jira/browse/SLING-1831?focusedCommentId=12920111&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12920111
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2329) Fix redirect loop prevention of
SlingAuthenticator
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170199#comment-13170199 ]
Felix Meschberger commented on SLING-2329:
------------------------------------------
Fix loop prevention in Rev. 1214752:
- Implement authenticationFailed method for HTTP Basic Authentication Handler to
force the client to provide different credentials
- Send 403/FORBIDDEN if a browser client causes a redirect loop (instead of
having the HTTP Basic handler send 401
> Fix redirect loop prevention of SlingAuthenticator
> --------------------------------------------------
>
> Key: SLING-2329
> URL: https://issues.apache.org/jira/browse/SLING-2329
> Project: Sling
> Issue Type: Bug
> Components: Authentication
> Affects Versions: Auth Core 1.0.6
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: Auth Core 1.1.0
>
>
> According to comment [1] in SLING-1831 the SlingAuthenticator.doLogin method sends back a 401 status in case of a browser-based login loop. This (Rev. https://fisheye6.atlassian.com/changelog/sling?cs=1021641) changes the Rev. https://fisheye6.atlassian.com/changelog/sling?cs=1021309 fix which caused a 403/FORBIDDEN to be sent back on login loop.
> Basically, this is wrong.
> The correct thing to do is:
> * If HTTP Basic credentials are provided, the browser will only let them go if a 401 status is received. This led to the Rev. 1021641 fix.
> * If no credentials are provided, the AuthenticationHandler would have been responsible for preventing such a loop. The Sling Authenticator just acts as a safety net here. This led to the Rev. 1021309 fix.
> The problem is, that both situations are actually valid and must be handled differently. Yet the correct way to handle the first situation is actually to implement the AuthenticationFeedbackHandler.authenticationFailed method in the HTTP Basic authentication handler: This method is called if authentication with credentials provided by an AuthenticationHandler are not valid. In the case of the HTTP Basic authentication handler, the Basic authentication credentials are invalid and the authenticationFailed method should thus send back a 401 response.
> Then, for the second case, the original Rev. 1021309 situation can be recreated again by sending a 403 in a perceived loop. This works because in the case of invalid HTTP Basic credentials the authenticationFailed method has already been called to send back the 401. In any other case it must be assumed the authentication handler ran havoc and thus authentication must be terminated.
> [1] https://issues.apache.org/jira/browse/SLING-1831?focusedCommentId=12920111&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12920111
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2329) Fix redirect loop prevention of
SlingAuthenticator
Posted by "Felix Meschberger (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved SLING-2329.
--------------------------------------
Resolution: Fixed
Added another integration test in Rev. 1214794 ensuring the correct status is returned on a request where the referrer matches the request URL. It used to be 401 which is wrong and now it should be 403.
Prevent sending 401 from the HTTP Basic Handler if the request is credentials validation where 403 is expected in Rev. 1214791
> Fix redirect loop prevention of SlingAuthenticator
> --------------------------------------------------
>
> Key: SLING-2329
> URL: https://issues.apache.org/jira/browse/SLING-2329
> Project: Sling
> Issue Type: Bug
> Components: Authentication
> Affects Versions: Auth Core 1.0.6
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: Auth Core 1.1.0
>
>
> According to comment [1] in SLING-1831 the SlingAuthenticator.doLogin method sends back a 401 status in case of a browser-based login loop. This (Rev. https://fisheye6.atlassian.com/changelog/sling?cs=1021641) changes the Rev. https://fisheye6.atlassian.com/changelog/sling?cs=1021309 fix which caused a 403/FORBIDDEN to be sent back on login loop.
> Basically, this is wrong.
> The correct thing to do is:
> * If HTTP Basic credentials are provided, the browser will only let them go if a 401 status is received. This led to the Rev. 1021641 fix.
> * If no credentials are provided, the AuthenticationHandler would have been responsible for preventing such a loop. The Sling Authenticator just acts as a safety net here. This led to the Rev. 1021309 fix.
> The problem is, that both situations are actually valid and must be handled differently. Yet the correct way to handle the first situation is actually to implement the AuthenticationFeedbackHandler.authenticationFailed method in the HTTP Basic authentication handler: This method is called if authentication with credentials provided by an AuthenticationHandler are not valid. In the case of the HTTP Basic authentication handler, the Basic authentication credentials are invalid and the authenticationFailed method should thus send back a 401 response.
> Then, for the second case, the original Rev. 1021309 situation can be recreated again by sending a 403 in a perceived loop. This works because in the case of invalid HTTP Basic credentials the authenticationFailed method has already been called to send back the 401. In any other case it must be assumed the authentication handler ran havoc and thus authentication must be terminated.
> [1] https://issues.apache.org/jira/browse/SLING-1831?focusedCommentId=12920111&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12920111
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira