[
https://issues.apache.org/jira/browse/HTTPCLIENT-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16259676#comment-16259676
]
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_r152082458
--- 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 --
canCache() is not specific to a particular auth scheme. I think it's better
than using an annotation because it allows one to control which schemes an auth
cache implementation can store, without having to write a new scheme class and
a new scheme factory. But since you're the man, if you would rather use the
annotation that's fine by me.
needsUpdatingAfterReusing() is needed to have the system re-cache a digest
scheme after reuse. As I explained in the scenario above, when a digest scheme
is allocated to a request, it should not be reused until a successful response
to that request is received.
The alternative is to change RequestAuthCache like in here
https://github.com/apache/httpcomponents-client/pull/88/commits/8a107d6ff40edfe2f83c6655ae1d816584deb0c4#diff-9ba10ad1fe707824930ac6fb842c871b.
That code I added calls
targetAuthExchange.setState(AuthExchange.State.CHALLENGED). I can put that call
inside an if (scheme is digest), so it's digest specific. The point is that
either the cache or the DigestScheme need to be told when the scheme has been
reused successfully and can be made available for new requests. Please let me
know if you have a different suggestion.
> 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]
