Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
Auth Core 1.0.6
-
None
Description
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.