[
https://issues.apache.org/jira/browse/HTTPCLIENT-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16258571#comment-16258571
]
ASF GitHub Bot commented on HTTPCLIENT-1855:
--------------------------------------------
Github user agherardi commented on a diff in the pull request:
https://github.com/apache/httpcomponents-client/pull/88#discussion_r151874368
--- Diff:
httpclient5/src/main/java/org/apache/hc/client5/http/auth/AuthCache.java ---
@@ -45,4 +45,8 @@
void clear();
+ boolean canCache(String name);
+
+ boolean needsUpdatingAfterReusing(String name);
--- End diff --
Yes. Consider the following scenario:
- The auth cache contains a DigestScheme for host H, with nonce=N and nonce
count=1
- Thread A needs to send a request to host H. The thread retrieves the
DigestScheme from the cache, increments nonce count to 2 and uses N to create
an Authorization header for its HTTP request.
- Thread B also needs to send a request to host H. If the cache returns the
same DigestScheme, thread B creates an Authorization header for its HTTP
request with nonce=N and nonce count=3.
- If thread B sends its HTTP request before thread A sends its HTTP
request, host H rejects thread B's request because the nonce count is 3 instead
of 2.
IMO, a DigestScheme needs to be removed from the cache until a response is
received from the server, so that no other thread can use the same nonce. If a
successful response is received from the server, the DigestScheme can be
re-cached with an updated nonce count.
I wrote a custom AuthCache that implements the behavior above. The cache
stores AuthSchemes unserialized. The cost of un-caching and re-caching
DigestSchemes for every message exchange is minimal, especially when compared
to the cost of a network roundtrip if the request needs to be resent due to the
nonce count being out-of-sequence.
The needsUpdatingAfterReusing method allowed me to implement the custom
AuthCache, which is not part of this merge request. BasicAuthCache's
implementation of needsUpdatingAfterReusing returns FALSE, so BasicAuthCache is
not updated on very message exchange - which is what you want.
> 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
> 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]
