You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2017/11/06 16:06:00 UTC

[jira] [Comment Edited] (HTTPCLIENT-1855) Digest auth: Nonce counter not incremented after reuse

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240482#comment-16240482 ] 

Oleg Kalnichevski edited comment on HTTPCLIENT-1855 at 11/6/17 4:05 PM:
------------------------------------------------------------------------

bq. Reusing the same HttpContexts may be problematic for some applications

Why? Why should it be problematic for any application? {{HttpContext}} represents a shared conversational state or a session state. Whether or not it is safe to mutate the session state concurrently is up to individual applications to decide, but generally {{HttpContext}} attributes can be threading unsafe. For instance, {{AuthScheme}} instances are not threading state. 

This issue has nothing to do with caching. In my opinion you are approaching the problem from a completely wrong angle. You want multiple threads to share the same DIGEST state? Fine, make DigestScheme threading safe. But this problem has _nothing_ to do with caching as such.

Oleg


was (Author: olegk):
bq. Reusing the same HttpContexts may be problematic for some applications

Why? Why should it be problematic for any applications? {{HttpContext}} represents a shared conversational state or a session state. Whether or not it is safe to mutate the session state concurrently is up to individual applications to decide, but generally {{HttpContext}} attributes can be threading unsafe. For instance {{AuthScheme}} instances are not threading state. This issue has nothing to do with caching. 

In my opinion you are approaching the problem from a completely wrong angle. You want multiple threads to share the same DIGEST state? Fine, make DigestScheme threading safe. But this problem has _nothing_ to do with caching as such.

Oleg

> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org