You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Keep digest authentication state, and reuse for following requests. #1467
The bug is reproducible against the latest release and/or master.
There are no similar issues or pull requests to fix it yet.
Describe the bug
DigestAuth will not re-use data from a previous challenge, and always start a new connection without authentication to get a new digest challenge. The requests library will re-use the authentication from first challenge.
First request against server should be without authentication, then follow-up requests on same Client instance, should re-use authentication data from first.
Actual behavior
Every request will start without authentication headers, then continue with an authenticated requests.
Debugging material
DEBUG:httpx._client:HTTP Request: GET https://tv2.local:1926/6/channeldb/tv "HTTP/1.1 401 Unauthorized"
DEBUG:httpx._client:HTTP Request: GET https://tv2.local:1926/6/channeldb/tv "HTTP/1.1 200 OK"
DEBUG:httpx._client:HTTP Request: GET https://tv2.local:1926/6/channeldb/tv/channelLists/all "HTTP/1.1 401 Unauthorized"
DEBUG:httpx._client:HTTP Request: GET https://tv2.local:1926/6/channeldb/tv/channelLists/all "HTTP/1.1 200 OK"
DEBUG:httpx._client:HTTP Request: GET https://tv2.local:1926/6/applications "HTTP/1.1 401 Unauthorized"
DEBUG:httpx._client:HTTP Request: GET https://tv2.local:1926/6/applications "HTTP/1.1 200 OK"
NOTE:
Please list tracebacks in full (don't truncate them).
The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the same credentials MAY be reused for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.
In this paragraph I understand the term "credentials" refers to the string we're putting as the Authorization: Digest <credentials> header.
Requests does seem to skip WWW-Authenticate if it has already authenticated:
Requests stores some local state (last_nonce, nonce_count, etc) to recreate the auth header, incrementing the client nonce each time. I assume if they're doing it then it's required, though we might be able to do things a bit more simply (eg just storing the entire challenge object). Or not — we'd need to dig a bit.
For reference, there was discussion about this when we introduced Digest auth: #332 (split from #305, which also has a ton of context).
At the time we explicitly left nonce counting (ie reuse) out. I think it was a mix of "auth classes should not store state" (?) and "how would we store local state while supporting sync and async".
Marking this as an "enhancement", and happy for anyone to dig deeper. :-)
Reproduction
# example.pyimporthttpxurl="https://httpbin.org/digest-auth/test/user/p@ssw0rd"auth=httpx.DigestAuth("user", "p@ssw0rd")
withhttpx.Client(auth=auth) asclient:
# First request: 401 WWW-Authenticate then 200 OK.r=client.get(url)
# Send new request, XXX: 401 WWW-Authenticate (again) then 200 OK.r=client.get(url)
# Send new request, but reusing `authorization` header.# This succeeds -- but should it?! Shouldn't the server expect the client to increase its nonce?request=client.build_request("GET", url, headers={"authorization": r.request.headers["authorization"]})
r=client.send(request)
I did a naive test that seem to work fine by storing state in the auth block:
classDigestAuthCached(httpx.DigestAuth):
_challenge=Nonedefauth_flow(self, request: httpx.Request) ->Generator[httpx.Request, httpx.Response, None]:
ifself._challenge:
request.headers["Authorization"] =self._build_auth_header(request, self._challenge)
response=yieldrequestifresponse.status_code!=401or"www-authenticate"notinresponse.headers:
# If the response is not a 401 then we don't# need to build an authenticated request.returnforauth_headerinresponse.headers.get_list("www-authenticate"):
ifauth_header.lower().startswith("digest "):
breakelse:
# If the response does not include a 'WWW-Authenticate: Digest ...'# header, then we don't need to build an authenticated request.returnself._challenge=self._parse_challenge(request, response, auth_header)
request.headers["Authorization"] =self._build_auth_header(request, self._challenge)
yieldrequest
Note. You need to remember the challenge, not just last authorization header since the header contains the requested URL.
Yup, you see, that's why we went the "don't worry, just re-auth each time for now" route. Lots of small things to think about to get this improvement in... Feasible, but not trivial. :)
changed the title [-]Digest authentication is not reused for following requests[/-][+]Keep digest authentication state, and reuse for following requests.[/+]on Mar 24, 2021
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Once we're tracking those two bits of state, then we're able to implement challenge reuse. If we've already got a challenge, then the auth flow can skip directly to _build_auth_header...
Activity
florimondmanca commentedon Feb 16, 2021
Hello!
You're right, RFC 2617 states that reuse of credentials is allowed:
https://tools.ietf.org/html/rfc2617#section-1.2
In this paragraph I understand the term "credentials" refers to the string we're putting as the
Authorization: Digest <credentials>header.Requests does seem to skip
WWW-Authenticateif it has already authenticated:https://github.com/psf/requests/blob/8c211a96cdbe9fe320d63d9e1ae15c5c07e179f8/requests/auth.py#L281-L283
But we don't, and instead always send a first unauthenticated request:
httpx/httpx/_auth.py
Lines 159 to 160 in 32d37cf
Requests stores some local state (
last_nonce,nonce_count, etc) to recreate the auth header, incrementing the client nonce each time. I assume if they're doing it then it's required, though we might be able to do things a bit more simply (eg just storing the entirechallengeobject). Or not — we'd need to dig a bit.For reference, there was discussion about this when we introduced Digest auth: #332 (split from #305, which also has a ton of context).
At the time we explicitly left nonce counting (ie reuse) out. I think it was a mix of "auth classes should not store state" (?) and "how would we store local state while supporting sync and async".
Marking this as an "enhancement", and happy for anyone to dig deeper. :-)
Reproduction
elupus commentedon Feb 16, 2021
I did a naive test that seem to work fine by storing state in the auth block:
Note. You need to remember the challenge, not just last authorization header since the header contains the requested URL.
elupus commentedon Feb 16, 2021
Should be added that the domain of the challenge should likely be used as some cache key to know where the auth can be re-used.
florimondmanca commentedon Feb 16, 2021
Yup, you see, that's why we went the "don't worry, just re-auth each time for now" route. Lots of small things to think about to get this improvement in... Feasible, but not trivial. :)
Add digest auth hack
[-]Digest authentication is not reused for following requests[/-][+]Keep digest authentication state, and reuse for following requests.[/+]stale commentedon Feb 20, 2022
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
elupus commentedon Feb 20, 2022
Still valid
stale commentedon Mar 25, 2022
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
elupus commentedon Mar 25, 2022
Still valid
stale commentedon Oct 15, 2022
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
elupus commentedon Oct 15, 2022
I think this is still valid.
lovelydinosaur commentedon Oct 17, 2022
Alrighty... here's how to tackle this one...
The
DigestAuthclass needs two extra bits of state to persist on instances.httpx/httpx/_auth.py
Lines 153 to 157 in 71ee50b
We need...
We should store the challenge as state on the instance, rather than just a local variable...
httpx/httpx/_auth.py
Line 175 in 71ee50b
Similarly with the nonce count, which we should track as state on the instance, and increment on each usage...
httpx/httpx/_auth.py
Line 225 in 71ee50b
Once we're tracking those two bits of state, then we're able to implement challenge reuse. If we've already got a challenge, then the auth flow can skip directly to
_build_auth_header...httpx/httpx/_auth.py
Lines 159 to 177 in 71ee50b
We'll need a test case to cover this too.
Anyone want to give this a go? 😃
rettier commentedon Nov 25, 2022
i came across this issue when noticing huge performance differences, i gave it a go at #2463
paulschmeida commentedon Nov 30, 2022
Not to mention that if you reauthenticate every request some servers will block you after 6-10 requests when using async.
lovelydinosaur commentedon Nov 30, 2022
Closed via #2463.