runtime: HttpClientHandler on Linux/OSX doesn't correctly implement Digest authentication
When making a request to a server requiring Digest authentication, the username is incorrectly specified as realm\\username
in the challenge response. WCF has an implementation of the digest authentication algorithm in our tests which the following is from. The details of the authentication handshake that we’re seeing uses the following credential information.
Username: be70abb0
Password: c84613c28bee44e5
Realm: bfd3c
A request is first made to the server with no authorization header. The server responds with a 401 Access Denied response and provides the following response header,
WWWAuthenticate: Digest realm="bfd3c", nonce="Ni8yNC8yMDE2IDEyOjMyOjI0IFBN", opaque="0000000000000000", stale=false, algorithm=MD5, qop="auth"
The client then sends the following response headers.
Authorization: Digest username="bfd3c\\be70abb0", realm="bfd3c", nonce="Ni8yNC8yMDE2IDEyOjMyOjI0IFBN", uri="//HttpDigestNoDomain.svc/http-digest-nodomain", cnonce="MTliMzMyYmFlNmZiZWZiMTAwMTE2NDQ4MDAwMDFjNjc=", nc=00000001, qop=auth, response="d632601dd17ae997ec1fd065da22cf7f", opaque="0000000000000000", algorithm="MD5"
The digest username sent is bfd3c\\be70abb0
which is realm\\username
. This is incorrect as the username should be sent without the realm.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 16 (16 by maintainers)
I investigated this same issue as part of dotnet/corefx#28065. I’m able to reproduce this issue even if I skip CurlHandler completely and use only Curl. Even using their escaping mechanism, I can’t make Curl send a single slash in a digest username. It either doubles the slash as you saw, or leaves it escaped.
Since this works in SocketsHttpHandler and appears to be an external bug without a workaround, I’m going to close this issue.