Allow for ports to be public by default

[wictorwilen]

I'd like to see an option in devcontainer.json where I can set a port to be public by default.

Example:

"portsAttributes": {
  "1234": {
    "label": "My public port",
    "privacy": "public"
  }
}

[mchelen-gov]

there's a otherPortsAttributes config key in https://code.visualstudio.com/docs/remote/devcontainerjson-reference but it doesn't have a lot of detail

[tanmayeekamath]

Hey @wictorwilen, thanks for your feedback. Currently we don't support this. I would love to learn more on your scenario/problem to address with this so that I can capture this in our backlog. Can you please share a bit more context here? :)

[tanmayeekamath]

Hey @treeder, can you share a bit more context on what app you're running?

I just tested on my end to be sure, restarting your app should not switch a public port back to private, Restarting the Codespace should switch it back to private since it is not a setting supported in the devcontainer.json just yet and the default behavior for all Codespaces is to keep all ports private from a security standpoint. The reason this is marked as an answer is because it is a feature request that we have captured in our backlog.

I would love to learn more on why restarting your app is switching the port back to private and help you resolve the issue there, looking forward to that :)

[treeder]

When I stop a process to recompile it, it closes the port (no longer in the Ports tab), then when I start it again, it opens the port again back to the default state which is private. This is the same for every single app/repo I open in Codespaces.

[tanmayeekamath]

Thanks for the quick response. This is likely happening because you haven't forwarded the port manually/automatically in your Codespace.

• Can you confirm if you are using the default codespaces image or if you have created a devcontainer configuration for it?
  • If you have a default image, are you forwarding the port manually? if it was forwarded manually, it will only disappear when the codespace is stopped.
  • If you have a devcontainer config, can you confirm if you have included the port that needs to be forwarded in your devcontainer.json file? If it is included, the port should automatically be forwarded every time you create the codespace.
    Ex. https://github.com/codespaces-contrib/save-june/blob/master/.devcontainer/devcontainer.json ("forwardPorts" section).

Here is a doc on how to forward ports in Codespaces: https://docs.github.com/en/codespaces/developing-in-codespaces/forwarding-ports-in-your-codespace

Feel free to reach out if you have follow up questions.

[treeder]

Ahh, that's a bit better, I added it to forwardedPorts so I only have to do it once when a codespace starts. Thanks for the tip. It would still be nice to have a way to set it public on startup though.

[ImAnAutie]

Hey @wictorwilen, thanks for your feedback. Currently we don't support this. I would love to learn more on your scenario/problem to address with this so that I can capture this in our backlog. Can you please share a bit more context here? :)

If its useful my usecase for this is to have the API server for my project default open so I can point the front end (running in a different repo) to the in development API.

[treeder]

Are there any plans to add this? This is still the most annoying thing with Codespaces. Every time I start it up I have to remember to change all my ports to public before I can start working.

[tanmayeekamath]

Hey @treeder! Thanks for following up on this. We've been discussing the right way to implement this considering this is a privacy related functionality wherein public ports are accessible by anyone with a link to that url and supporting a public by default setting means providing a larger surface area for resources to be exposed to the public internet with a potential of users forgetting about that setting and it applying to all their codespaces.

As a workaround, you can set this using dotfiles and the gh cli. Add code in one of the files listed (install.sh, install, bootstrap.sh, etc…) that uses the gh cli to change port visibility based on the individual users preference. If the gh cli isn’t already installed in the Codespace, the installation can also be handled in the dotfiles before attempting to change port visibility. That way, every time you create a new codespace, the port visibility will be set to the desired value.

Would this address your need in the short term?

[rthomps7]

That's what it looks like to me too, but it works. However we still have pretty inconsistent behavior on codespace ports in general. Sometimes they timeout. Sometimes they hang forever.

[liorbrauer]

@tanmayeekamath the issue with using dotfiles to get the command to automatically run when the codespace starts is that it's a user's personal setting whether the dotfiles are run or not. I want to be able to have the ability to run a start script for anyone who is trying to run my repo in a codespace.

I tried using the postStartCommand property in a devcontainer.json file but it didn't seem to work. Is there a way to consistently run a start script in the dev container once it's initialized? (basically, I want to run gh codespace ports visibility 3000:public -c $CODESPACE_NAME once everything is ready and ports have been forwarded)

[rthomps7]

Try doing it on the postAttachCommand slot. That works for us.

Again we have plenty of port problems, but it does make them public

[liorbrauer]

@rthomps7 thanks, I've actually tried this but without success. I've added to my main .devcontainer/devcontainer.js file the following:

{
    //...
    "postAttachCommand": "gh codespace ports visibility 3000:public -c $CODESPACE_NAME"
}

But when the container starts, I run gh codespace ports -c $CODESPACE_NAME and the visibility is still private. Only after I manually run the port visibility command and list the ports again do I see it change to public.

Would you be able to share a (redacted) version of your devcontainer.json file that works?

[x-danma]

{
    //...
    "postAttachCommand": "gh codespace ports visibility 3000:public -c $CODESPACE_NAME"
}

This approach works now.

[treeder]

Any progress on this?

[rthomps7]

I understand the security concerns holding this up. Perhaps an equally (or more) valuable solution would be some exposure to what ports are forwarded to locally, so that you can have servers communicate with each other programmatically and not need the public ports.

Right now the issue we run into is port 3000 may need to talk to port 5000, but if that happens client-side (e.g. on my browser), I need a reliably URI to use for communication. The "githubpreview.dev" links work, but you can't have them talk through private ports because there is a redirect auth thing that will fail. As such we need to make them public.

I'd be happy sticking with local ports, but port 3000 and 5000 are unreliable since devcontainers will find any available port if that port is taken (e.g. two codespaces are up)

[treeder]

I honestly don't get the security concerns. If I want a public port, I obviously don't care about the security of that port.

[rthomps7]

Yeah. Unfortunately we've had so much trouble with the public ports working, hanging, etc I'm not entirely sure default configs will solve the problems we've had. We now have a boot script that makes them public, but the reliability is low.

[liorbrauer]

@rthomps7 could you share how you're setting up boot scripts in codespaces?

[treeder]

GitHub should really just take a page out of Gidpod's playbook. They've had this feature for a long time. You just set in your config file you want it public, then you don't need to deal with it again.

[michaelmior]

Just to add use case, in my case I want this because I'm running a small Elasticsearch container along with a React app that needs to access the ES instance. I actually don't necessary want it to be public, but that's the only way to make this work now.

[liorbrauer]

Same here, I basically have a frontend and backend app and the only way to make the frontend app be able to communicate with the backend without getting a CORS error is to set the backend app's http port to public.

[rthomps7]

Lior - do you have the gh cli setup on the image? My needs for the frontend/backend connection are the same. I don't need it public either and could use localhost ports, but the locally forwarded ports are not deterministically detected so I use public ports. I actually think a more valuable addition to codespaces would be somehow passing information about port forwarding to some config inside the container. I studied it a bit but didn't find any way. Surely it's doable, but I haven't sorted it out yet. My issues with the public ports are strictly reliability. They sometimes have ssl issues, sometimes get gateway errors, sometimes hang. It's maybe 5-10% if the time, but it causes 5-10% downtime of the dev team.

On Fri, Sep 2, 2022 at 2:40 PM Lior Brauer ***@***.***> wrote: Same here, I basically have a frontend and backend app and the only way to make the frontend app be able to communicate with the backend without getting a CORS error is to set the backend app's http port to public. — Reply to this email directly, view it on GitHub <#4068 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJYYZBNJDFHB3SSINMLTZTV4JJZHANCNFSM454KE4NA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- [image: Company logo] *Bobby Thompson* Chief Technology Officer ***@***.*** | 913.314.2520 <9133142520> *Uhray* | uhray.com <https://www.uhray.com/> 1220 Washington St, Ste 200 Kansas City, MO 64105 [image: facebook icon] <https://www.facebook.com/pages/category/Consulting-Agency/Uhray-452145365121537/> [image: linkedin icon] <https://www.linkedin.com/company/uhray/>

[liorbrauer]

hey @rthomps7, thanks for the reply!

Regarding your described idea:

I actually think a more valuable addition to codespaces would be somehow passing information about port forwarding to some config inside the container.

I wonder how would that work? Because when I want to test my app in codespaces, I open a tab with the frontend app (on port 3001) which loads fine with a url pattern of xxxx-3001.githubpreview.dev, but when the browser makes requests to the backend app, it's on a different subdomain (due to different port), so ends with xxxx-3000.githubpreview.dev, and the request is rejected due to a CORS issue (that is only resolved if the 3000 port is manually set to public). Not sure any configs could circumvent this, unless codespaces changes its internal header/CORS settings to automatically allow all calls between ports of the same codespace.

To your first question - I do have the gh cli setup on the image. My devcontainer.json file contains the forwardPorts property to make sure they are forwarded from the get-go (port 3000). Then I have a little script file that I call in postAttachCommand that runs the gh codespace ports visibility 3000:public -c $CODESPACE_NAME command.

I verified it is being called successfully by looking at the container creation.log file (CMD+Shift+P -> 'Codespaces: View Creating Log') and I even print out the port statuses there to make sure they turned public (gh codespaces ports -c $CODESPACE_NAME).

Everything looks in order, but when I run the show ports command in the Codespace terminal (again with gh codespaces ports -c $CODESPACE_NAME) it shows it as private and not public. If I manually change it to public, it will stick. But I want it to already be public using the postAttachCommand script.

My suspicion is this is a timing issue, where the ports are forwarded, set to public (by my script) but then somewhere after that and before I gain control in the codesapce, the ports are reset.

[rthomps7]

I'm not sure what's up with your setup. I'm roughly doing the same thing and it does stick. The only difference is I call a bash script that then calls the gh command. But given you log everything out and it says public, doesn't sound likely to be the issue to me. Only other thought I have is if your servers are booting up on start too, so it's triggering something with the codespace and the port. Nothing on my machines boot up immediately so I'm not putting anything on say port 3000 for some seconds after boot (once I run commands manually) As for my recommendation, I haven't thought of how the info would get passed around, but my point was you'd stick with localhost. But say 3000 forwarded to 3100 on your machine, you'd open localhost:3100. You'd then need to know what port the backend forwarded to (say 5000 forwarded to 5100). If this information is present on the machine somehow, you could cause your 3000 server to point the browser at 5100 not 5000. Fwiw - if you're never at risk of two codespaces, the above would likely work and you just hardcode 3000. That's not my scenario since the biggest value of codespaces for me was to pop up multiple Likely the port forwarding is occurring on your local machine not the codespaces so it would need to get passed back. I have not dug deep enough yet, but to me it's an incredibly limiting feature of containerized dev environments to not easily connect to servers to talk to each other.

On Sat, Sep 3, 2022 at 1:35 PM Lior Brauer ***@***.***> wrote: hey @rthomps7 <https://github.com/rthomps7>, thanks for the reply! Regarding your described idea: I actually think a more valuable addition to codespaces would be somehow passing information about port forwarding to some config inside the container. I wonder how would that work? Because when I want to test my app in codespaces, I open a tab with the frontend app (on port 3001) which loads fine with a url pattern of xxxx-3001.githubpreview.dev, but when the browser makes requests to the backend app, it's on a different subdomain (due to different port), so ends with xxxx-3000.githubpreview.dev, and the request is rejected due to a CORS issue (that is only resolved if the 3000 port is manually set to public). Not sure any configs could circumvent this, unless codespaces changes its internal header/CORS settings to automatically allow all calls between ports of the same codespace. To your first question - I do have the gh cli setup on the image. My devcontainer.json file contains the forwardPorts property to make sure they are forwarded from the get-go (port 3000). Then I have a little script file that I call in postAttachCommand that runs the gh codespace ports visibility 3000:public -c $CODESPACE_NAME command. I verified it is being called successfully by looking at the container creation.log file (CMD+Shift+P -> 'Codespaces: View Creating Log') and I even print out the port statuses there to make sure they turned public (gh codespaces ports -c $CODESPACE_NAME). Everything looks in order, but when I run the show ports command in the Codespace terminal (again with gh codespaces ports -c $CODESPACE_NAME) it shows it as private and not public. If I manually change it to public, it will stick. But I want it to already be public using the postAttachCommand script. My suspicion is this is a timing issue, where the ports are forwarded, set to public (by my script) but then somewhere after that and before I gain control in the codesapce, the ports are reset. — Reply to this email directly, view it on GitHub <#4068 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJYYZENNDQC2BN3UCE4KXDV4OK65ANCNFSM454KE4NA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- [image: Company logo] *Bobby Thompson* Chief Technology Officer ***@***.*** | 913.314.2520 <9133142520> *Uhray* | uhray.com <https://www.uhray.com/> 1220 Washington St, Ste 200 Kansas City, MO 64105 [image: facebook icon] <https://www.facebook.com/pages/category/Consulting-Agency/Uhray-452145365121537/> [image: linkedin icon] <https://www.linkedin.com/company/uhray/>

[liorbrauer]

To anyone following this thread, I actually got it working consistently, but with kind of a hacky solution. Sharing here if anyone was looking for working solution (copied my answer from another question):

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!

[mlschechter]

@valhuber - Thanks for providing a sample project. I just tried to spin it up in a Codespace, and the port remains private. Could you please let me know if this is a problem with my user settings, or if the visibility command just not working as expected?

I'm having the same issue with a repository I'm working on, so this matches my experience but not my expectations.

Thanks!

[valhuber]

@mlschechter Yes, you are correct. I assumed my "make public" attempt worked, since the app ran (after generation) - in the past, private ports did not return data. I also thought I checked port visibility, but I might be mistaken. I just repeated it, and you are correct, it is private.

My current best-project is here. And, I have documented the approach I used to make it public (or to try).

I am very eager to get this working, and cleanly, and am more than happy to meet if that makes it easier for you...

[mlschechter]

I figured it out - I was using the UI (the Ports tab) to check the status, and that never changes. I can change it one way, and then override it from the command line, and the UI never changes from my manual setting.

So, everything works as you indicate in your examples - thank you again for providing them!

One thing to note - apparently Codespaces uses nginx under the hood for port routing, and I had one codespace during testing where the nginx configuration appeared to be corrupted, and I could not get the port forwarding to work no matter what. All I got were 502s.

Hope this helps!

[valhuber]

@mlschechter Ah, right, had actually suspected that.

So it is working, somewhat solidly - ? Do you believe the approach I used is correct, and what you folks want customers to do?

You might also want to check out my remaining issues, in particular the ability to create from templates. I understand that feature is in progress, and am happy to help testing...

[mlschechter]

I think the approach you used is as clean as we can get unless they modify the devcontainer specification to allow for port visibility settings. The fact that the UI doesn't refresh is also something outside our control.

For what I need in the short term, I think I'm pretty much set.

Thanks again for the detailed reference!

[omarkohl]

One reason for this feature is that currently CORS does not work with private ports. The API port always needs to be made public. See this discussion: https://github.com/orgs/community/discussions/15351

[SubhamSubhasisPatra]

https://docs.github.com/en/codespaces/developing-in-codespaces/forwarding-ports-in-your-codespace Follow this doc for code space.

[mlschechter]

If this is being set up for less experienced developers, asking them to do this is an extra step that they have to be coached through. It should be able to be set up as a default setting in the Codespaces configuration.

[treeder]

How is this still not a thing? A year and a half since this discussion started. Seems like one tiny little setting could enable this. We know it's already there since I have to do it every single time I open a codespace, but can't we just have the ability to save that setting?

[mottersheadt]

Agreed with @treeder. This feature will make codespaces way more usable as a full development environment. Would appreciate if ports could be pre-configured as "public" rather than having to repeatedly change the setting.

[mikehudson2]

Is there at least a way to start e.g. a node server server with a command line switch stipulating that it should use listen on a particular port and that its visibility should be public?

Obviously a persistent visibility setting would be better, though. Seems silly not to have that functionality.

[devAbreu]

I recently had the same problem and managed to get it running as follows.

Create a shell script file (e.g., change_port_visibility.sh) in your project directory with the following content:

#!/bin/bash

# Function to change port visibility
change_port_visibility() {
  local port=$1
  local visibility=$2
  gh codespace ports visibility $port:$visibility -c $CODESPACE_NAME
}

# Usage: change_port_visibility <port> <visibility>
change_port_visibility $1 $2

This script takes two arguments: the port number and the desired visibility.

2. In your devcontainer.json file, add the following configuration:

   {
     "name": "Your Dev Container",
    "features": {
    	"github-cli": "latest"
    },
   "forwardPorts": [
    	3000,
    	3001
    ],
    "portsAttributes": {"3000": {"label": "Main app"}},
    "postCreateCommand": "/bin/bash ./.devcontainer/change_port_visibility.sh 3000 public"
   }

Replace Your Dev Container with an appropriate name for your development container. Adjust the port number and visibility according to your needs.

The postCreateCommand property specifies the command to be executed after creating the Codespace. In this case, it runs the shell script with the arguments 3000 and public to change the visibility of port 3000.

3. Place the change_port_visibility.sh script in a subdirectory called .devcontainer within your project directory.

With these configurations, the change_port_visibility.sh script will be executed automatically after creating the Codespace, updating the port visibility based on your specified arguments.

After that, you can check with gh codespace ports -c $CODESPACE_NAME to see the ports visibility.

Note: In the Tab Ports, It remains private. But again, you can check with the previous command in terminal.

I write about it in Spanish in my blog Automate the visibility of Ports in your Codespaces with a Bash Script

[treeder]

I can't say for sure, but all of a sudden it seems to have started remembering when you set a port to be public. Can anyone else confirm this on their end?

[tidkeavanade]

is there a declarative way yet to do it ?

[treeder]

And now it forgets again...

[bboru21]

Yeah, my experience for the past year was that it defaulted to what I had selected (public), but the past couple months or so it seems to be private by default again.

[treeder]

Yep, super annoying....