Port Visibility & CORS

[chadhietala]

I spent the past couple days trying to figure out how to resolve a CORS related problem within Github Codespaces. Consider the following scenario:

• App is served on port 3000 and is assigned the URL https://chad-my-project-abc231-3000.githubpreview.dev
• API is served on port 7007 and is assigned the URL https://chad-my-project-abc231-7007.githubpreview.dev
• From the browser app tries to fetch a todos from https://chad-my-project-abc231-7007.githubpreview.dev/api/todos

As of right now the only way you can do this is if you set the port visibility on the API server (7007) to Public. Both Private and Private to Organization seem to block the requests. I believe that there is a need to make the port accessible to the organization but not Public.

With Public Port Visibility

With Private to Organization Port Visibility

[weiklr]

I have the same problem as well. anyone had any luck solving this without using public visibility?

[jan-grosser]

Unfortunately we have the same problem, did anyone find a solution?

[liorbrauer]

The only solution I have currently found other than manually setting this via the gui is running:

gh codespace ports visibility 3000:public -c $CODESPACE_NAME

In the codespace terminal. However, that only works once the port has been forwarded, and I still don't have a consistent way of automatically running the command once the server is up.

[mohdali]

gh codespace ports visibility 3000:public -c $CODESPACE_NAME

I tried this approach, but it doesn't change to public unless the port is already listening. So I have to wait till my API server is started then manually change to public.

Is there any way to predefine as public regardless of if the port is currently listening?

[liorbrauer]

hey @mohdali (and anyone following this), I actually got it working consistently, but with kind of a hacky solution. Sharing here if anyone was looking for working solution:

1. Added a .devcontainer/devcontainer.json file and configured the ports I want to be made public to be auto-forwarded. This helps make sure that when we later run the gh codespace ports command it will take effect, since the port will already be assigned and forwarded (and doesn't need to wait for you to run your own process that assigns the port):

(devcontainer.json)

{
  "forwardPorts": [3000, 3001]
}

2. Then I also add a command to run a custom bash script file (setup.sh) under postAttachment script to be run when the container is first booted:

(devcontainer.json)

{
  "forwardPorts": [3000, 3001],
  "postAttachCommand": "/bin/bash .devcontainer/setup.sh",
}

3. In the setup.sh file I added I first tried just running the gh codepsace ports command (gh codespace ports visibility 3000:public -c $CODESPACE_NAME) but it still wasn't consistent. My suspicion is a timing/racing-condition issue. So to get around that I did kind of a hacky thing, I added the follow command to append the gh codespace ports command to the .bashrc file so that the command will run every time we open a terminal window. The code looks like this:

(setup.sh)

echo "gh codespace ports -c $CODESPACE_NAME" >> ~/.bashrc

This basically works consistently, but is kind of hacky. (Also, if your codespace users use zsh instead, you need to do the same for the ~/.zshrc file, etc.)

Hope this helps!

[mohdali]

@liorbrauer thanks a lot for this. I can live with it in the meantime but I don't like how complicated it is and the main intention is to enable CORS not to make the API public.

Hope we will get a better way soon.

My aim is to allow users try the application in codespaces. So I need to reduce the friction as much as possible.

[patrickkmatias]

I've faced this issue recently and I did create a open-port.sh script to open automatically in codespaces or gitpod after 5 seconds. With it I can call it only when it is needed like:

"dev:cloud": "./vite/open-port.sh & npm run dev",

Note that it is important to be used with the & operator (not &&) to run at the same time as the second command; otherwise the second command would be called only after the script has ran and would throw an error, because the port wouldn't be exposed yet.

#!/bin/bash
# After 5 seconds, turn Vite port to public and show no command output on CLI
sleep 5
if [ -n "$CODESPACES" ]; then
    gh codespace ports visibility 5173:public -c $CODESPACE_NAME > /dev/null 2>&1
elif [ -n "$GITPOD_WORKSPACE_URL" ]; then
    gp ports visibility 5173:public > /dev/null 2>&1
else
    echo "Neither CODESPACES or GITPOD_WORKSPACE_URL environment variable is set"
fi
#
# This script is intended to be used only in Browser cloud environment,
# because of a issue involving bad handled preflight requests when
# the port is private from Github and Gitpod parts.
# @see https://github.com/community/community/discussions/15351

[acho1833]

It's really weird that there's no official solution to this yet. Thanks for your script! Now I know 'sleep' command in bash!

[mohdali]

Hi,

I'm facing the same issue. Is there any other solution to provide CORS headers without changing to public?

[omarkohl]

As far as I can tell this is due to the fact that the preflight OPTIONS request is not supposed to contain authentication information (and the browser does not send it!), but the GitHub Codespaces server is expecting this info and otherwise rejects the request.

Preflight requests and credentials

CORS-preflight requests must never include credentials. The response to a preflight request must specify Access-Control-Allow-Credentials: true to indicate that the actual request can be made with credentials.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials

I ran into the same issue with Gitpod and made a detailed bug report for them, so far without response. gitpod-io/gitpod#14576 To me it seems to be exactly the same issue and considering how similar Gitpod and GitHub Codespaces look, I assume they are based on the same code base.

EDIT: As mentioned in a different comment, I created an example repository to reproduce this issue. https://github.com/omarkohl/gh-codespaces-cors

[liorbrauer]

As far as I can tell this is due to the fact that the preflight OPTIONS request is not supposed to contain authentication information (and the browser does not send it!), but the GitHub Codespaces server is expecting this info and otherwise rejects the request.

Preflight requests and credentials

CORS-preflight requests must never include credentials. The response to a preflight request must specify Access-Control-Allow-Credentials: true to indicate that the actual request can be made with credentials.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials

I ran into the same issue with Gitpod and made a detailed bug report for them, so far without response. gitpod-io/gitpod#14576 To me it seems to be exactly the same issue and considering how similar Gitpod and GitHub Codespaces look, I assume they are based on the same code base.

Interesting, I will take look at your reported issue, thanks for sharing!

Fwiw, you are correct, as far as I know gitpod basically wraps the vscode code base, so definitely similar issue (noticed it as well).

[cmuto09]

Hey @chadhietala- thanks for the report!

This is a known issue, and we are determining the best approach to fix it. @omarkohl is exactly right that the underlying issue is the OPTIONS request not allowing authentication of org or private port based scenarios from the web-based IDE.

Using public ports will work, but you can also work around this by connecting to your codespace via VS Code Desktop rather than the web based browser. VS Code Desktop enables you to privately forward ports from your codespace to your local machine directly (at localhost:<port>). Using this method does not trigger the authentication flow that is blocking your current requests.

This workaround does not help for org-based ports though since those require publicly accessible URLs, which will fail on authentication again.

[omarkohl]

I created a Git repository with a minimal example to reproduce this with GitHub Codespaces. Can be used for debugging or to verify someday that the issue has been fixed. https://github.com/omarkohl/gh-codespaces-cors

[davidlahuta]

So any progress on this?

[jprosevear]

@cmuto09 circling around on this - is there a plan? Makes simple monorepo usage painful in a secure way.

[billy1kaplan]

Any updates on this? This would be a really useful feature to have!

[howieyuen]

I disable chrome plugin: chrome://flags/#block-insecure-private-network-requests, and works for me!!!

[omarkohl]

This must be a different issue. The examples listed above don't use private IPs. You might run into issues with private IPs when forwarding to VS Code Desktop.

If you want to verify you can try https://github.com/omarkohl/gh-codespaces-cors in the browser only (without VS Code Desktop) and you will see disabling the "Block insecure private network requests" Chrome setting won't help.

[o0stephen0o]

Since I need to work outside, which the computer can't be installed anything that I must use it on the web.
I disable the plugin and make the port I need to connect to be public
finally, they can connect and the CORS error was disappeared. Thanks for your help!

[theforgottenwizard]

I spent the past couple days trying to figure out how to resolve a CORS related problem within Github Codespaces. Consider the following scenario:

• App is served on port 3000 and is assigned the URL https://chad-my-project-abc231-3000.githubpreview.dev
• API is served on port 7007 and is assigned the URL https://chad-my-project-abc231-7007.githubpreview.dev
• From the browser app tries to fetch a todos from https://chad-my-project-abc231-7007.githubpreview.dev/api/todos

As of right now the only way you can do this is if you set the port visibility on the API server (7007) to Public. Both Private and Private to Organization seem to block the requests. I believe that there is a need to make the port accessible to the organization but not Public.

With Public Port Visibility

With Private to Organization Port Visibility

Helped me solve my problem. Thanks for sharing.

[Hetnon]

so 2 years later and no answer??
is it serious that not every project trying to use codespace hit this wall?

[hamzashadeez]

This is weird really

[Jhohny]

In my case, port 5000 was still returning a CORS error even after stopping my container app. I ran lsof -i :5000 to check if something else was using this port locally, and I found the following running on port 5000:

$ lsof -i :5000
ControlCe 1800 mbp14    8u  IPv4 0xfe25a9e6585f8167      0t0  TCP *:commplex-main (LISTEN)
ControlCe 1800 mbp14    9u  IPv6 0x9bcddd7518115a5f      0t0  TCP *:commplex-main (LISTEN)

I discovered this process was related to macOS AirPlay. I changed my container app to use a different port, and that resolved the issue.