[
https://issues.apache.org/jira/browse/HTTPCLIENT-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243368#comment-16243368
]
Alessandro Gherardi commented on HTTPCLIENT-1855:
-------------------------------------------------
{quote}
Why should it be problematic for any application?
{quote}
Consider a webservice application which processes requests from one or more
webservice clients. To service multiple client requests concurrently, the
application uses a pool of worker threads. Each request is processed by a
separate worker thread. When a worker thread has finished processing a request,
the thread goes back to to the pool of available threads. This is a very common
design pattern for webservices.
As part of processing client requests, the application must communicate with
one or more network devices via HTTP. The devices require digest
authentication. The application stores credentials for the various devices in
its database.
Let's suppose the webservice application receives a request that requires it to
communicate with device A. The request is assigned to a worker thread. The
worker thread creates a new HttpContext. If this is the first time that the
application communicates with A, httpclient receives a HTTP 401 with a digest
challenge, creates a digest scheme containing device A's nonce and uses the
scheme and the device credentials to re-send the request with an Authorization
header containing the challenge response. The device validates the
Authorization header and replies successfully.
The worker thread is now done processing the client response and returns to the
pool of available threads.
In order for the digest scheme containing device A's nonce to be reused by a
worker thread the next time the application needs to communicate with device A,
the application must store either the HttpContext or the digest scheme in some
kind of cache, using device A's IP as the cache key.
In summary, re-using HttpContext is not complicated, but basically requires
implementing something very similar to httpclient's auth cache. It would be
nice if that functionality was provided by httpclient via its auth cache so
applications don't have to reinvent the wheel.
Hope the above makes sense.
> 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]
