Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CURLOPT_UNRESTRICTED_AUTH man page: No mention of Authorization header behaviour #8724

b-spencer opened this issue Apr 19, 2022 · 3 comments


Copy link

The docs for CURLOPT_UNRESTRICTED_AUTH imply that "credentials" means "user+password" and nothing else, but this optional actually controls various different kinds of authentication information.

A security bulletin from a few years ago clarifies that, specifically, the Authorization header is no longer forwarded to different hosts, and experiment confirms that current curl does still behave this way.

To be clear, the current behaviour is good! :)

I suggest that the documentation for CURLOPT_UNRESTRICTED_AUTH be clarified to indicate precisely which kinds of authentication it controls. It's not only "user+password" (such as could be set by CURLOPT_USERPWD, which is linked-to from this doc page), but also any application-provided Authentication header, and I think also any headers set internally by various other curl-supported authentication mechanisms.

I'm not sure of the total list of what this controls, so I haven't drafted a doc patch myself. It would be helpful to me as an API user if I could look at the CURLOPT_UNRESTRICTED_AUTH docs and know immediately:

  • that my custom-set Authentication headers are not forwarded to other hosts when this is 0, and
  • which curl-generated headers or authentication information is not forwarded to other hosts when this is 0,

and also that such headers are forwarded when this is 1.

Thanks again!

@bagder bagder self-assigned this Apr 19, 2022
bagder added a commit that referenced this issue Apr 19, 2022
Include details about Authentication headers.

Reported-by: Brad Spencer
Fixes #8724
Copy link

bagder commented Apr 19, 2022

Give #8726 a look!

Copy link
Contributor Author

Looks great!

(Do I close this or do I let #8726 close it automatically?)

Copy link

bagder commented Apr 19, 2022

Just leave it. 8726 will close this automatically when we merge that!

@bagder bagder closed this as completed in 774dbd5 Apr 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Successfully merging a pull request may close this issue.

2 participants