[
https://issues.apache.org/jira/browse/HTTPCLIENT-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239000#comment-16239000
]
Alessandro Gherardi commented on HTTPCLIENT-1855:
-------------------------------------------------
[~olegk] thanks for continuing to look into this.
My thoughts:
* Reusing the same HttpContexts may be problematic for some applications. For
instance, consider an application with a worker thread pool. When the
application receives a request from a client, it processes the request on a
worker thread. As part of the processing, the thread makes a call to an HTTP
server that requires authentication. The next time the application needs to
talk to the HTTP server, it may do so on a different worker thread. To reuse
the HttpContext, the application would have to implement some sort of
HttpContext cache. That's effectively the same as using an auth cache
* Allowing an application to decide whether or not to cache DigestSchemes
depending on some configuration parameter would be great
* No issues with
https://github.com/ok2c/httpclient/commit/d88e32f9525f36bbbb46dc212648fd484e70a072,
although that commit by itself doesn't allow the application to decide whether
or not to cache DigestSchemes
* Regarding setting the auth exchange state to CHALLENGED in RequestAuthCache,
that is to force an updated DigestScheme - with an incremented nonce counter -
to be re-cached after reuse.
Basically, the desired outcome is as follows:
* The first time we successfully authenticate to an HTTP server that requires
digest authentication, cache the DigestScheme
* The next time we need to talk to that server, retrieve a DigestScheme from
the cache (if available), remove it from the cache so that no other thread can
reuse it until the request is complete, and use the DigestScheme to
preemptively build an authorization header. As part of this, the nonce counter
within the DigestScheme is incremented.
* If authentication is successful, re-cache the updated DigestScheme so it can
be later reused for another request
* If authentication is not successful, don't re-cache the updated DigestScheme
- probably the nonce has expired. Instead, create a new DigestScheme using the
digest challenge we receive from the servers and the credentials, retry the
request using the new DigestScheme to authenticate and if successful cache the
DigestScheme.
> Digest auth: Nonce counter not incremented after reuse
> ------------------------------------------------------
>
> Key: HTTPCLIENT-1855
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1855
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.5.2
> Reporter: Alessandro Gherardi
> Priority: Major
> Attachments: HttpClient5Digest.java, HttpClientDigest.java,
> httpclient5.log, wireshark.txt
>
>
> I have a client app using httpclient 4.5.2 with BasicCredentialsProvider and
> BasicAuthCache. and web server that requires HTTP digest authentication.
> The client sends 3 requests to the web server.
> When the app sends the first request, the server returns an HTTP 401 with a
> digest challenge. httpclient automatically retries the request with the
> Authorization header. The header contains the nonce returned by the server
> and a nonce counter (nc) of 1. The retry succeeds and httpclient caches the
> DigestScheme.
> For the second request, httpclient uses the cached DigestScheme to calculate
> the Authorization header pre-emptively. The header contains the same nonce
> and specifies a nonce counter of 2. The request succeed without requiring a
> retry.
> For the third request, httpclient uses the cached DigestScheme to calculate
> the Authorization header pre-emptively. Even though the header contains the
> same nonce, the nonce counter is set to 2 again. This causes the server to
> return a 401. httpclient should have incremented the nonce counter to 3.
> I believe that the root cause of this problem is that, although DigestScheme
> increases the nonceCount field every time the authenticate() method is
> called, HttpAuthenticator does not re-cache DigestScheme after reusing it.
> The re-cache is needed because BasicAuthCache stores DigestScheme in
> serialized format.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]