Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Authentication state is not reset properly when using NTLM #1095
I did this
This example program performs two requests. libcurl does not send the request body for the second request - that's the bug.
I expected the following
libcurl sends the request body for the second request.
The bug appears even if
For NTLM, the flag
All NTLM state should be attached to the current connection. It's wrong to attach it directly to the easy handle. Probably a refactoring is necessary to fix this bug properly.
Reproduced here, with simple digest auth. (curl 7.51.1)
Only destroy and re-create handle do the trick
I think it could be reproduced by setting ntlm on the first request to a server which does not require authentication, then post body is omitted from the subsequent request (even if the connection is not reused and the easy is reset between operations).
Reproduction with '--next' (git-master), against a server on localhost which simply echos back post body:
I think, the digest issue may be related as in digest flow we also may not set authhost.done to true.
To my understanding, authhost.multi is used when we know that authentication is not complete yet (we expect 401), that's in order to avoid posting the data unnecessarily.
As such, I think it will be safe to clear authhost.multi at http_done() after the flag was used, since even if we'll be still expecting yet another 401 (unlikely), we'll be passing again at output_auth_headers() and it will be set back to true if necessary.
I don't think it will conflict with multiple auth-methods, in that case the local 'auth' variable in output_auth_headers() does not get set, and so auth.multi gets set to false (then the request gets sent without any auth header and we get the list of supported auth methods from the server and we pick one auth from the intersection of wanted and supported auth-methods).
yup. my concern was multi might also be used for starting the auth, for example imagine if there was some code like
I am going to add a test and I will land this tomorrow/Wed, if there are no objections.
This flag is meant for the current request based on authentication state, once the request is done we can clear the flag. Also change auth.multi to auth.multipass for better readability. See discussion at curl#1095 Signed-off-by: Isaac Boukris <email@example.com> Reported-by: Michael Kaufmann
We should also clear the whole auth state at the bottom of
I don't understand why
... but obviously that's not what
Maybe we should have a better fix for curl_easy_reset, I've seen similar. Perhaps we should make a new handle, move over pointers to what is documented to still exist, cleanup the original handle and then memcpy that whole new handle back into the original handle. I'm still in the thought stage but how does that sound. The only problem that could stick is if anything in the new handle is a pointer to itself, though tests would catch it if that happened.