[
https://issues.apache.org/jira/browse/HTTPCLIENT-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944133#comment-13944133
]
bitfire commented on HTTPCLIENT-1489:
-------------------------------------
I'm happy that I've never had to bother with NTLM authentication. According to
http://www.innovation.ch/personal/ronald/ntlm.html, the syntax is always either
{noformat}
WWW-Authenticate: NTLM <base64-encoded block>
{noformat}
which would be compliant with RFC 2616, or just
{noformat}
WWW-Authenticate: NTLM
{noformat}
which is a problem because 1) it is clearly missing the required auth-param
(they should have taken realm, for instance), and 2) the parameter isn't
compliant to the auth-param syntax definition (token "=" ( token |
quoted-string )).
So, to parse the string, I suggest (pseudo-code):
{noformat}
splitStrings = split(WWW-Authentication header value, ",")
foreach string in splitStrings
; string can now either be
; 1. a parameter for the current authentication scheme OR
; 2. a new "auth-scheme auth-param" pair
; 3. illegal value: "auth-scheme" without auth-param (NTLM)
; 4. illegal value: "auth-scheme auth-param-without-name" (NTLM)
; for case 1
if (string matches /(TOKEN_DEF)=(VALUE_DEF)/) ; where the possibility
of quoted VALUE_DEF has to be taken into account
assert currentAuthScheme is not null
currentAuthScheme.parameters.add string
; cases 2, 3, 4
else
s = split(string, " ")
if s.count == 1 ; case 3
currentAuthScheme = new AuthScheme(s[0])
elseif s.count == 2 ; cases 2 and 4
currentAuthScheme = new AuthScheme(s[0])
currentAuthScheme.parameters.add s[1]
else
throw exception("unparseable www-authenticate header")
endif
endif
{noformat}
> Multiple, comma-separated challenges in WWW-Authenticate are not recognized
> ---------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1489
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1489
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.3.3
> Reporter: bitfire
> Labels: authentication, parsing
> Fix For: 4.4 Final
>
>
> As per RFC 2616, WWW-Authenticate may contain more than one challenge:
> »User agents are advised to take special care in parsing the WWW-
> Authenticate field value as it might contain more than one challenge, or if
> more than one WWW-Authenticate header field is provided, the contents of a
> challenge itself can contain a comma-separated list of authentication
> parameters.« [https://tools.ietf.org/html/rfc2616#section-14.47]
> For instance, https://contacts.icloud.com returns such a WWW-Authenticate
> header:
> > GET / HTTP/1.1
> > Host: contacts.icloud.com
> > Accept: */*
> >
> < HTTP/1.1 401 Unauthorized
> < ...
> < WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle", Basic
> realm="Newcastle"
> The X-MobileMe-AuthToken challenge is recognized by HttpClient, but the Basic
> challenge is not. HttpClient logs when sending a GET request to
> https://contacts.icloud.com:
> [DEBUG] headers - http-outgoing-0 << HTTP/1.1 401 Unauthorized
> [DEBUG] headers - http-outgoing-0 << Date: Fri, 21 Mar 2014 19:20:14 GMT
> [DEBUG] headers - http-outgoing-0 << X-Apple-Request-UUID:
> d1d0aa7d-d651-4da2-be9f-595f1619db85
> [DEBUG] headers - http-outgoing-0 << X-Responding-Instance:
> carddav:12100701:st13p21ic-quav11230703:8001:14B52:125783
> [DEBUG] headers - http-outgoing-0 << WWW-Authenticate: X-MobileMe-AuthToken
> realm="Newcastle", Basic realm="Newcastle"
> [DEBUG] headers - http-outgoing-0 << Content-Length: 0
> [DEBUG] MainClientExec - Connection can be kept alive indefinitely
> [DEBUG] HttpAuthenticator - Authentication required
> [DEBUG] HttpAuthenticator - contacts.icloud.com:443 requested authentication
> [INFO] TargetAuthenticationStrategy - GOT Auth header: X-MobileMe-AuthToken
> realm="Newcastle", Basic realm="Newcastle"
> [DEBUG] TargetAuthenticationStrategy - Authentication schemes in the order of
> preference: [negotiate, Kerberos, NTLM, Digest, Basic]
> [DEBUG] TargetAuthenticationStrategy - Challenge for negotiate authentication
> scheme not available
> [DEBUG] TargetAuthenticationStrategy - Challenge for Kerberos authentication
> scheme not available
> [DEBUG] TargetAuthenticationStrategy - Challenge for NTLM authentication
> scheme not available
> [DEBUG] TargetAuthenticationStrategy - Challenge for Digest authentication
> scheme not available
> [DEBUG] TargetAuthenticationStrategy - Challenge for Basic authentication
> scheme not available
> The Basic auth challenge is NOT recognized!
> Reason: org.apache.http.impl.client.AuthenticationStrategyImpl:getChallenges
> iterates through the WWW-Authenticate HEADERS but doesn't take account that a
> single header may contain multiple challenges.
> How to fix:
> Split and parse the WWW-Authenticate header correctly in
> org.apache.http.impl.client.AuthenticationStrategyImpl:getChallenges
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
