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

selecting proxy authentication type #2

Open
stefankuhr opened this issue Oct 9, 2015 · 1 comment
Open

selecting proxy authentication type #2

stefankuhr opened this issue Oct 9, 2015 · 1 comment

Comments

@stefankuhr
Copy link

Hello everyone,

we are using the cpp rest sdk (currently version 2.4) in an http client using ssl within a bigger project where we allow users to specify ip and port of a proxy server and in addition the authentication method they want to use/allow (basic or ntlm). It seems like the authentication method within the rest sdk is done automatically (ChooseAuthScheme in http_client_winhttp.cpp) depending on the capabilities of the proxy server. So in our scenario it is possible for our users to (erroneously) specify IP and port address of a server that only allows basic auth while specifying ntlm as their only and preferred auth method. However, the cpp rest sdk code will happily detect that the proxy server that the user chose only supports basic auth and so it will use basic auth and reveal users' credentials. Is there a way to use the http client functionality in such a way that we can specify not only ip address, port and proxy credentials but also to specify the authentication method we prefer, so that a client call will fail if the server doesn't support the auth method we specified?

Any help appreciated,

Stefan Kuhr

@ras0219-msft
Copy link
Contributor

This is a good scenario that we currently don't have any APIs for.

I think the easiest way to quickly add this in would be to pipe another parameter through the http_client_config object, then use the property inside handle_authentication_failure to filter the allowed auth schemes.

My concern with adding that as an official API is portability to our boost::asio implementation. I would imagine that asio has the capability for this, but I don't know for sure. It would need further investigation.

atbagga pushed a commit to atbagga/cpprestsdk that referenced this issue Oct 26, 2021
…llback_once

linux: invoke the certificate chain callback only once
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants