-
Notifications
You must be signed in to change notification settings - Fork 199
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
Error accessing authenticated endpoint with plain HTTP endpoint [HTTPError: Only https is supported] #5486
Comments
Hi @thelazydogsback , Your best way forward is probably to create a new "DangerousAzureIdentityAcccesTokenProvider" that derives from the original one, replaces http by https, and calls the base method. Let us know if you have additional questions. |
@baywet i think that approach a pain in the ass, i use kiota for in cluster communications inside k8s using bff architecture, so there is no security problem, there is no access to external urls, i realy think that must be a better way around that, an easy one |
Thank you for the additional information. On the technical side, the change "is easy". Simply add another setting the the authentication/access token providers to drive the condition which enforces the use of HTTPS. What I'm questioning is whether we should make it easy, at the risk of making it easy to build unsecured applications and compromising customers. Maybe if we named the setting "DangerousDisableHttpsVerification" or something along those lines it make this distinction clear? I'd like to get the input of our architect @darrelmiller before we more forward with this one. |
Thanks @SilverioMiranda and @baywet. |
Thanks @baywet - I was able to implement your suggestion by overriding
and providing a subclass of So I'm good for now, but will remove this code if there is a configurable option in the future. |
Thank you for the additional information. An alternative (and arguably better) design here would be to make the localhost_strings configurable with a better name like "HostsToAllowHttp" or something like that. It could reuse the entirety of the ValidHosts infrastructure, leading to minimal duplication in the implementation. But again, I'll like a sign off from @darrelmiller before we proceed here. |
There is ongoing discussion in the IETF about sending credentials to APIs over HTTP(S) https://www.ietf.org/archive/id/draft-rsalz-httpapi-privacy-00.html following the blog post a few months ago about the risks of redirecting HTTP to HTTPS. Some people are of the opinion that APIs should only be exposed via HTTPs. richsalz/draft-rsalz-httpapi-privacy#7 I don't have a strong objection to making it possible to turn off HTTPS as long as it is clear that it is not a recommended approach. |
Thanks @darrelmiller . That makes sense to me for APIs exposed to the outside world, but I'm not sure I see the reasoning if none of the endpoints are even reachable at all except from other internal services that are in the same vnet, and also check that the caller is whitelisted, etc. HTTPS is pretty fast, but it's not free. (A few hundred ms for handshakes and 10-20% overhead thereafter?) |
Thanks for chiming in. On the spirit of the ask: while there's probably no risk for a loopback scenario, there's probably still some risk on a microservices scenario, even running on a single host. All those containers are relying on IPs, names, and DNS to communicate with each other. A compromised container could in theory start sending new IPs, change the DNS resolution and start observing clear HTTP traffic. Hopefully the network stack for the container engine guards against that through firewalls preventing containers from doing DHCP, but that's not a guarantee. So yes, it should be clearly called out. But let's experiment with what it'd mean to open this up a little more. @SilverioMiranda @thelazydogsback would one of you be willing to submit a draft PR with:
|
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. |
What are you generating using Kiota, clients or plugins?
API Client/SDK
In what context or format are you using Kiota?
Windows executable
Client library/SDK language
Python
Describe the bug
I am trying to access an authenticated HTTP endpoint - not HTTPS.
However it appears that authentication must take place over HTTPS.
Expected behavior
Both the authentication call and the final api call should succeed
How to reproduce
The following code using only httpx works fine when the baseUri is "http://mySvc".
Note this is an authenticated service-to-service call within a single Azure Container vnet - only an HTTP endpoint is exposed, not HTTPS.
However, using this kiota generated client:
Does not work when calling
client.foos.by_id(id)
. The error I get is:This appears to be because that while my actual internal service call needs to be plain HTTP, then auth call needs to be HTTPS.
How do I get the kiota client to behave like the httx code, (apparently) still using HTTPS to get the token, but using HTTP to access my endpoint?
Open API description file
No response
Kiota Version
1.17.0+1eb16cd65853c17179e2dde3ae6098135deacf55
Latest Kiota version known to work for scenario above?(Not required)
No response
Known Workarounds
No response
Configuration
No response
Debug output
Click to expand log
```The text was updated successfully, but these errors were encountered: