Add feature to have Cors Configuration on Port forwarding, or be able to use base url port forwarding

[aleleba]

          Also should be great to have Cors Configuration on Port forwarding, or be able to use base url port forwarding, something like: https://{randomKey}.use.devtunnels.ms/proxy/{portNumber}, for avoid cors issues, right now I am trying to develop an application that have a front-end app server, and a back-end server, both running on different ports, so I am having Cors issues when trying to fetch back-end project. Thank you in advance @bamurtaugh.

Originally posted by @aleleba in https://github.com/microsoft/vscode-remote-release/issues/8771#issuecomment-1662971596

[aleleba]

As we talked on https://github.com/microsoft/vscode-remote-release/issues/8771 , It should be great to have Cors Configuration on Port forwarding, or be able to use base url port forwarding, something like: https://{randomKey}.use.devtunnels.ms/proxy/{portNumber}, for avoid cors issues, right now I am trying to develop an application that have a front-end app server, and a back-end server, both running on different ports, so I am having Cors issues when trying to fetch back-end project. Thank you in advance @bamurtaugh.

[aleleba]

Hi, maybe @alexr00 I can help on free time, if you give me some guidance, thank you so much 😁

[aleleba]

@alexr00, I am not sure, but I think the logic should be here, https://github.com/microsoft/vscode/blob/83fc3ad9bd553869e8fea3d370d1d2bd438f9e54/src/vs/workbench/electron-sandbox/window.ts#L894

[aleleba]

Hi @alexr00, to give more context of the issue, I am getting the cors error and the message of provisional headers.

It saids that is missing headers

In the back-end I am adding a whitelist of urls, to let the url to be accesible in cors rules.

and in front-end I am calling the back-end url, and I am reciving the error.

I think that maybe there are some cors rules in the proxy server that are blocking the requests, I know that the code is right, because it works in another dev environment that I have, as you see, there are different origins in the whitelist, and it work with different origins. Only in this port forwarding in the urls that vscode.dev throws I get the error.

When I run the same apps and use dev-front-end.p-lao.com origin for front-end and dev-back-end.p-lao.com as backend origin, this are different origins, I am able to call api.

Please let me know when you read this to know if there are some following up of this issue, and I will be able to help or solve any doubt of the issue, thank you in advance 😄

[alexr00]

@connor4312 do you think this should be done in the dev tunnels tunnel provider?

[aleleba]

Adding some another tests I have made, when using as back-end origin dev-back-end.p-lao.com and front-end origin as url of tunnel it worked, so my asumption of the cors I think that is true, I am trying to give you as much information I can.

[connor4312]

I don't think it should be done by us at all. Port forwarding doesn't change the HTTP request. While they could do this on the service side, I believe the correct behavior is for the user to add CORS headers to their local server if that's deemed necessary. These same rules would be needed to make cross-origin requests on localhost.

I verified that a server which responds to requests with CORS headers has those preserved and served to clients over port forwarding.

[alexr00]

Sounds good, thanks @connor4312!

[connor4312]

Ah, actually. Dev tunnels stores their authentication for private tunnels a cookie with the SameSite=lax attribute set. They would need to set SameSite=none in order for programmatic cross-site requests to be made, otherwise it redirects to get authentication for private tunnels.

[aleleba]

Thank you @connor4312 for found the issue, I am really exited to get the fix, to be able to migrate totally to this environment 😁

[aleleba]

Hi @derekbekoe, hope you are doing well, I think the change should be on file: vscode/src/vs/server/node/webClientServer.ts on this lines: https://github.com/microsoft/vscode/blob/fffde1001afa6207a084a9ea63c78702626802a1/src/vs/server/node/webClientServer.ts#L254 and https://github.com/microsoft/vscode/blob/fffde1001afa6207a084a9ea63c78702626802a1/src/vs/server/node/webClientServer.ts#L391 , hope this help, I will be attentive for response 😁

[aleleba]

Also I think this should fix https://github.com/microsoft/vscode-remote-release/issues/8800 this too, not sure but I think this will fix the simple browser too. Maybe is the cookie the one that is missing to be able to enter to the page on simple browser.

[aleleba]

Maybe if @derekbekoe is busy, I can make the Pull Request, can I help with something?

[derekbekoe]

As @connor4312 mentioned above, the behavior you're seeing is due to the Dev tunnels service, not VS Code client. Also, it's likely due to the fact that the port has access set to private (requiring authentication); currently all ports hosted from vscode.dev Remote Tunnels get set to private.

With that said, here are a couple options that I believe should work:

1 - Set the "backend" port in your example to public While vscode only supports private today, it's still possible to change this using the devtunnel CLI. Here are the steps:

# download the CLI for your OS - https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/get-started#install
# log in via GitHub
devtunnel login -g
# verify the tunnel id shows in the list of tunnels (this is the id in the *.devtunnels.ms url)
devtunnel list
# make the port public
devtunnel access create TUNNELID --port-number 4000 --anonymous

Now that the port is public, re-test your scenario.

Note that this makes the port accessible to anyone with the url without authentication. Other ports will remain private. Also, it may take 30s to 60s for the change to take effect.

2 - Use an access token to access the port

It is possible to also keep the tunnel private and get a token you provide in the header of the request to your backend.

• With the devtunnel cli, you can run devtunnel token TUNNELID --scope connect which will output a token.
• When your frontend is making the API call, add the header to authenticate the request: X-Tunnel-Authorization: tunnel TOKEN Learn more at https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/security#tunnel-access

[aleleba]

Thank you! I will try that and let you know 😁

[aleleba]

@derekbekoe, @connor4312, I have tested and it worked, but I think that for the final user it should be useful that vscode handles this for them and create a fetch interceptor where attaches the X-Tunnel-Authorization: tunnel TOKEN behind the scenes on every request. What do you think?

Because each token expires every two days, so maybe when creating a forwarding port, vscode can create a new token and attach it with the interceptor the header.

[derekbekoe]

Glad it worked.

It may be unexpected if VS Code started adding this header automatically to user requests. In addition, it is not always needed and it may not translate well to other languages or frameworks.

I see a couple possible ways to improve the experience here:

• Support is added for switching individual ports to Public, without the need for the devtunnel CLI
• Support is added for getting a tunnel access token directly e.g. via a UI element (this would be similar to Visual Studio)

It may be best to have separate issues for those.

[aleleba]

@derekbekoe , thank you!, agreed with you, can this features be on planning of developing? 😁

[connor4312]

Those two ideas are doable, and I think setting ports to public is something we'd want to do anyway. I am concerned though that it is very unclear to users who hit this issue that setting the port to public or using an access token is the right thing to do.

Maybe if Dev Tunnels see an different Origin header in the request, it can respond with some descriptive error in the response body rather than redirecting for authentication?

[aleleba]

@connor4312 I can help on the documentation of the feature when it is finished to develop, this will help to final users understands in what case use this features, count with my help of any task you want to assign, and I will help on my free time 👍🏼

[burkeholland]

While this can be done manually, the ideal model (I think) would be similar to Codespaces where localhost is perfectly emulated. As is, I would prefer to use Remote Tunnels, but I default to Codespaces because of the ease of working with ports.

[aleleba]

Hi @connor4312, @derekbekoe, hope you are doing great, I want to make a following up of this feature, if the team is thinking to add support to this?, thank you! 👍🏼

It seems that you are working on it?, or are this docs outdated?

Visibility option does not appeard to me.

This seems to be only available only on local, it should be great to have the same behavior on vscode tunnels too. Please give following up to this feature., thank you for the patience.

[aleleba]

Hi @derekbekoe does there are some following up of this work?, thank you in advance 😄

[aleleba]

Any update of this?

[achertovsky]

same here. FE application together with backend application. as its in fact 2 different hosts i have cors issue and no clue how to sort it out

[aleleba]

@connor4312 any update for this?

[aleleba]

Sorry to be so impatient, but I did not have any response since a month ago, @connor4312, do we have any update for this, thank you in advance.

[ntaraujo]

I'm also interested. Please, any updates?

[aleleba]

Hi @connor4312 , I have some avaiability to help. With some docs I think I can help to move this feature to a reality, may I help?

[aleleba]

@connor4312 do you know if there is a plan to integrate this?

[aleleba]

@derekbekoe @connor4312 , any plans for this, thank you in advance 👍🏼

[derekbekoe]

@aleleba For security reasons authentication is per tunnel-port so the options are as previously outlined in this previous comment.

You could either make the backend port public or make an authenticated request but passing in the tunnel access token. Making the port public is now straightforward in VS Code as it allows you to set the port to Public.

[aleleba]

Glad it worked.

It may be unexpected if VS Code started adding this header automatically to user requests. In addition, it is not always needed and it may not translate well to other languages or frameworks.

I see a couple possible ways to improve the experience here:

• Support is added for switching individual ports to Public, without the need for the devtunnel CLI
• Support is added for getting a tunnel access token directly e.g. via a UI element (this would be similar to Visual Studio)

It may be best to have separate issues for those.

As we discuss here, we talked about be able to open public ports automaticly for dev-tunnels, just as local vscode do, in local vscode you can change to use a public or private tunnel.

I know this should be very usefull for a lot of developers that are using dev-tunnels to work.

[derekbekoe]

Ah okay so Port Visibility is available on local VS code but not when using Remote - Tunnels to connect to a remote machine.

[aleleba]

@derekbekoe That is right, thank you for your response.

[achertovsky]

any updates on cors in tunnel? is it possible to configure headers via application now?

[aleleba]

Any update on this? thank you for adding this to the Backlog 👍🏼

[connor4312]

Ports forwarded over Remote Tunnels can be set as "Public" using the latest VS Code Insiders and REmote - Tunnels extension.

[aleleba]

Hi, on the insiders.vscode.dev is not possible yet, right? connor4312

[ajmeese7]

I'm not seeing it on that site either @aleleba, running into the same issue:

I've found that I can't access my API on port 1337 using a URL like https://bw1vqn78.use.devtunnels.ms:1337/ whatsoever, and that I can access https://bw1vqn78-1337.use.devtunnels.ms/ in the browser as expected, but run into CORS issues whenever trying to access the second URL method from the app I'm running on port 3000. Any kind of fix/workaround for this would be greatly appreciated, I've tried dozens of variations of fetch but the issue still stems from the lack of a permissive Access-Control-Allow-Origin header that allows requests from the same domain.

Code I'm using for reference, although I'm pretty sure the issue is independent of the code:

const getApiServerEndpoint = () => {
  let hostname = window.location.hostname;
  if (process.env.NODE_ENV === "development" && hostname.endsWith("use.devtunnels.ms")) {
    // Support for VS Code tunnels during development
    hostname = hostname.replace(/-\d{4}/, "-1337");
    return window.location.protocol + "//" + hostname;
  } else {
    return process.env.REACT_APP_API_SERVER;
  }
};

const healthCheckInterval = 2500;
const checkHealth = async () => {
  await fetch(getApiServerEndpoint() + "/parse/health", {
    signal: AbortSignal.timeout(5000),
    redirect: "follow"
  })
    .then(async (res) => await res.json())
    .then(
      (result) => { setIsBackendReady(true); },
      (error) => {
        console.warn("Error parsing health check data:", error);
        setIsBackendReady(false);
      }
    )
    .catch((error) => {
      console.warn("Failed health check:", error);
      setIsBackendReady(false);
    });

  // This way instead of setInterval to avoid multiple concurrent requests,
  // because the server occasionally hangs when under heavy load
  setTimeout(checkHealth, healthCheckInterval);
};

[aleleba]

I'm not seeing it on that site either @aleleba, running into the same issue:

I've found that I can't access my API on port 1337 using a URL like https://bw1vqn78.use.devtunnels.ms:1337/ whatsoever, and that I can access https://bw1vqn78-1337.use.devtunnels.ms/ in the browser as expected, but run into CORS issues whenever trying to access the second URL method from the app I'm running on port 3000. Any kind of fix/workaround for this would be greatly appreciated, I've tried dozens of variations of fetch but the issue still stems from the lack of a permissive Access-Control-Allow-Origin header that allows requests from the same domain.

Code I'm using for reference, although I'm pretty sure the issue is independent of the code:

const getApiServerEndpoint = () => {
  let hostname = window.location.hostname;
  if (process.env.NODE_ENV === "development" && hostname.endsWith("use.devtunnels.ms")) {
    // Support for VS Code tunnels during development
    hostname = hostname.replace(/-\d{4}/, "-1337");
    return window.location.protocol + "//" + hostname;
  } else {
    return process.env.REACT_APP_API_SERVER;
  }
};

const healthCheckInterval = 2500;
const checkHealth = async () => {
  await fetch(getApiServerEndpoint() + "/parse/health", {
    signal: AbortSignal.timeout(5000),
    redirect: "follow"
  })
    .then(async (res) => await res.json())
    .then(
      (result) => { setIsBackendReady(true); },
      (error) => {
        console.warn("Error parsing health check data:", error);
        setIsBackendReady(false);
      }
    )
    .catch((error) => {
      console.warn("Failed health check:", error);
      setIsBackendReady(false);
    });

  // This way instead of setInterval to avoid multiple concurrent requests,
  // because the server occasionally hangs when under heavy load
  setTimeout(checkHealth, healthCheckInterval);
};

Hi, the only way right now is to set in the headers of the app this X-Tunnel-Authorization: tunnel TOKEN, in the conversation behind you can see a reference to the docs on how you can achive connect a front-end and a back-end running on different ports, but as far as I know right now they are working on a way to connect it without this token. Hopefully this come soon.

[aleleba]

I want to update, on insiders.vscode.dev is working now 👍🏼 , I am exited to see this feature on stable release 👍🏼

[aleleba]

@connor4312 It seems to not work yet, when I set public the visibility it ask for credentials, so it not changed to public.

But running on local it works, so is a problem with tunnels itself.

I am not sure if is not working because of is not deployed to prod or is for a different issue, can you confirm?

[aleleba]

any update?, can I help in something?

[aleleba]

I found that is not working right, can anyone let me know if you are working on the fix?

[aleleba]

Hi @connor4312 , sorry for bother you, I only want to confirm that the team knows about the last issue?

[connor4312]

It seems to not work yet, when I set public the visibility it ask for credentials, so it not changed to public.

Make sure the tunnel process you're running is also VS Code Insiders / the VS Code Insiders CLI, as that is required for the port to actually be marked as public.

This will also release to stable in ~2 days.

[connor4312]

Closing as this has been complete and will be released shortly.

[aleleba]

You are right @connor4312 , I have downloaded vscode insiders, created a tunnel with the insiders version, and it worked, thank you for your help, very appreciated all the effort of all team members. Very exited to test it on stable release 👍🏼

[aleleba]

Hi @connor4312 , it seems that vscode have been updatedd but the stable release for remote-tunnels extension is not yet deployed, right? The plan was to deploy together?