Hi,
Reproduce with:
Setup:
curl_easy_setopt (m_curl, CURLOPT_FOLLOWLOCATION, 1);
curl_easy_setopt (m_curl, CURLOPT_UNRESTRICTED_AUTH, 0L);
Authorization header set with CURLOPT_HTTPHEADER
Case:
HttpStatus Found with redirect to different host
Result:
Authorization header is sent to different host
Expected:
(fails) Authorization header is not sent when redirecting to different host
This does not seem to be by design. We are using token based authorization, so curl API for setting USERNAME and PASSWORD authentication cannot be used.
Related code:
http.c(717): result = output_auth_headers(conn, authhost, request, path, FALSE);
Thanks
Well, it's not really clear how libcurl should act if you pass in a custom Authorization: header. The documentation says "it can continue to send authentication (user+password) credentials when following locations" but as far as it knows, it doesn't send any user+password.
Are you suggesting it should check custom headers and not send "Authorization:" to other sites if this option is set? To me it feels like perhaps stepping a little too far off from what that option is "allowed". After all, you set the custom headers yourself so you should be able to make sure you set the correct headers. Don't you think?
Yes, but curl still limits redirect functionality to only using username+password with known auth types. Nowadays token authentification is common, but that is not supported. As an example there could be CURLOPT_AUTHROIZATION option that could be used to set header and allow curl to handle redirects as it does with username+password auth.
Ah yes, another option could indeed be a way to solve it. Alternatively, we introduce a second value to set CURLOPT_UNRESTRICTED_AUTH to, to have it also affect custom Authorization: headers. Ĺike make it a bitfield or something.
Expanding CURLOPT_UNRESTRICTED_AUTH seems like a good idea as will make minimal changes to API and minimal changes in code using curl. It would nicely cope with backward compatibility also. This is better than using option to set authorization header as that would require not to set it with CURLOPT_HTTPHEADER witch would lead to more obscure code.
Last edit: lietus 2014-09-05
So, any chance you can write up a patch for this and send to the curl-library mailing list for discussion and review?
Unfortunately no
That's unfortunate, because this is not a prio feature for me to work on personally. Also, as this is not an actual bug I will move this issue to the feature-request tracker instead.
Ticket moved from /p/curl/bugs/1421/
Can't be converted: