[ 
https://issues.apache.org/jira/browse/SLING-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger reopened SLING-1831:
--------------------------------------


Reconsidering the chosen approach...

While 403/FORBIDDEN might make some sense on a technical level, it is of no 
help and use to end user experiencing the problem. What shall such a user do ? 
Restart the browser ? How does she/he know ?

The primary situation for such a loop is the browser repeatedly sending wrong 
HTTP Basic Credentials, which can only be solved by sending a 401 response to 
the browser. Other authentication handlers, basically those based on Cookies 
for authentication generally implement the authenticationFailed method to 
actually clear wrong cookies.

Thus insetad of sending back 403 we could check whether HTTP Basic 
Authentication is enabled fully or preemptively and send back 401 in this case. 
We still have to fall back to 403 if HTTP Basic Authentication is fully 
switched off.

Sending back 401 causes the browser to remove the wrong credentials from its 
cache and allows the client to either login with the browser login box or 
dismiss the box and try accessing the server without credentials again.

> Prevent Login Request loop
> --------------------------
>
>                 Key: SLING-1831
>                 URL: https://issues.apache.org/jira/browse/SLING-1831
>             Project: Sling
>          Issue Type: Improvement
>          Components: Authentication
>    Affects Versions: Auth Core 1.0.2
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: Auth Core 1.0.4
>
>
> Depending on AuthenticationHandler specifics it is conceivable that the Sling 
> Authenticator support may enter an endless redirect loop with the client.
> Consider this:
>   #1 client provides wrong credentials (e.g. cookie, HTTP Basic 
> authentication header)
>   #2 authenticator decides to call AuthenticationHandler.requestCredentials
>   #3 authentication handler sends a redirect to the client
>   #4 client requests redirect target again providing wrong credentials
>   #5 authenticator decides to call AuthenticationHandler.requestCredentials
>   #6 continue with step #3
> This loop should be broken in the authenticator: As soon as the authenticator 
> recognizes a (potential) redirect loop, the authentication handler should not 
> be called again but instead an immediate error response should be sent back.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to