Open danwatford opened 2 years ago
Fixed by #524
@sgollapudi77 - this is not complete - still two other items that need to be addressed.
Please see last part of the issue text and reopen.
I'm working on the other items at the moment.
Thank you @danwatford for identifying this issue and working on it.
Please finish this, it's very important for us
Are there any news regarding this issue?
We are also facing problems trying to work locally in the front-end app pointing to the remote azure function.
Is your feature request related to a problem? Please describe. To develop static web apps with functions that take advantage of managed identity it is necessary to deploy the functions to an functions-app separate to the swa-app and then link them together. This is referred to in the documentation as Bring Your Own Functions.
A solution which makes use of Bring Your Own Functions will often use two git repositories to store the SWA and the function-app sources.
With remote development approaches such as codespaces or docker containers becoming more common, it is likely that the developer will find themselves running/debugging the SWA and the function-app on different network hosts. They may also deploy the function-app to Azure and want to run/debug their SWA app locally.
When the function-app is running on a different network host to the swa-cli, the developer will need to specify the URL to the function-app as an HTTPS URL. Currently the swa-cli does not support this use case, but can be made to do so with a few changes.
Describe the solution you'd like
Support proxying of API requests to APIs hosted on remote hosts, using HTTPS URLs.
Allow use of insecure connections to the remote API similar to the
-k | --insecure
command line option in curl. This is to handle the case where the API host is using wildcard certificates which do not appear to be accepted by the http-proxy node module used by swa-cli.When proxying requests to the remote function-app, swa-cli should rewrite the host header to match the URL of the function app. Without this the function-app host will receive a request with a Host header of /localhost/ and will respond with a 404.
Describe alternatives you've considered When running the function-app in GitHub codespaces, port 7071 can be shared publicly. I tried making this available over HTTP, but this does not appear to supported for public ports.
VS Code will forward ports in codespaces to the local development host. I then tried using ngrok to make the local port available at a public HTTP URL which could be accessed by the swa-cli running in another codespace, but ran into connection issues around wildcard TLS certs used by ngrok.
Additional context Setting a remote URL with the
--api-location option
toswa-cli start
causes swa to attempt to resolve the URL as a filesystem directory. It is necessary to also specify the--api-devserver-url
option.However specifying
--api-devserver-url
only causes swa-cli to not be aware of any API server settings since conditional logic prevent--api-devserver-url
being examined if--api-location
is not also specified. Therefore in testing (of updates to swa-cli) I had to use command lines similar to:Changes needed to support this use case
net.ts
parseUrl
function should return port 443 for HTTPS URLs. Currently it returns 0 which causes a timeout in subsequent connection checking. See https://nodejs.org/dist/latest-v16.x/docs/api/url.html#urlport which explains the parsed port from a URL can be an empty string. PR #524 merged.(Update 2022-10-03: No longer needed. Only the host header change, mentioned below, is necessary for TLS connections to remote API hosts)msha/handlers/function.handler.ts
should optionally callhttpProxy.createProxyServer
with{ secure: false }
to prevent connections to remote function-apps failing due to wildcard TLS certificates. Addressed in PR #534.msha/handlers/function.handler.ts
injectHeaders
function should set thehost
header to match the host of the remote function-app. Without this change thehost
header will remain set tolocalhost
and proxied request will likely fail to get routed corrected at the remote host. Addressed in PR #578.With the above changes I was able to connect swa-cli to a remote function-app addressed via an HTTPS URL.