hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bitfire (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1489) Multiple, comma-separated challenges in WWW-Authenticate are not recognized
Date Sun, 23 Mar 2014 18:54:42 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944533#comment-13944533
] 

bitfire commented on HTTPCLIENT-1489:
-------------------------------------

{quote}
The direct consequence of that is if now we make auth challenge parsing more compliant we
are more likely to break all non RFC 2617 auth schemes that do not follow param=value rule.
{quote}

Which schemes would that be, besides NTLM?

Maybe it would be an option to provide a setting "workaround for non-compliant WWW-Authenticate
headers" (which defaults to false)? If NTLM is required (mostly in Intranet solutions), this
setting could be turned on and thus non-compliant parsing enabled.

But I still think that the algorithm above should work for both standards-compliant headers
and NTLM.

> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message