-
Notifications
You must be signed in to change notification settings - Fork 125
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
feat(start): allow insecure https connections to remote api hosts #534
Conversation
Allow insecure connections to remote api hosts to handle cases where remote TLS host presents a wildcard certificate. Change the host header in proxied requests from localhost to match the remote api host. Relates to Azure#523
Hey @danwatford , thanks for your contribution! I was thinking that maybe this could be something that could be always activated as it's a proxy to a dev server anyways? @manekinekko what do you think? |
We are going to be adding support for @danwatford have you tried using the |
Hi @manekinekko Issue #534 mentions how http-proxy doesn't handle wildcard certificates from remote API hosts. This PR is a workaround in that http-proxy is (optionally) instructed to ignore any remote host certificate authentication. Assuming the new support for However if there are plans to replace http-proxy with something that can handle wildcard certificates then this PR should not be necessary. |
Hi @sinedied , It might be acceptable to leave the insecure connection option enabled by default, but if we did that then we should probably log a warning to the user that we have not authenticated the connection to the remote API server. I don't know if we can assume users will always be proxying to a development server. My preference would be to ensure a secure connection by default, but log some guidance about using the insecure connection option if they have any connectivity issues. |
This is the plan.
There are no plan to replace http-proxy.
In order to avoid any breaking changes or unexpected side effects, I'd recommend adding this flag but turning it off by default and allowing users to enable it on demand. cc @sinedied @sgollapudi77 @sulabh-msft |
@danwatford can you please update the corresponding documentation to add this flag, and also an usage example? |
Some good(ish) news. While updating the documentation I wanted to capture the error text that users might see for problems connecting to remote API hosts, but couldn't recreate the problem that was intended to be solved by the --api-devserver-insecure command line option. Testing against APIs accessed GitHub Codespaces public ports or via locally developed APIs accessed via Ngrok were no longer failing. I tracked down the cause of the unintended successful connection to the I think I had misinterpreted errors such as:
as http-proxy having issues with wildcard certificates. I had failed to notice the Conclusion: This PR can be closed and I will raise a new PR to apply the |
Allow insecure connections to remote api hosts to handle cases where remote TLS host presents a wildcard certificate.
Change the host header in proxied requests from localhost to match the remote api host.
Relates to #523