[ 
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]

Reply via email to