Feature: Sharable ports

[mtojek]

Problem

Customers want to be able to expose arbitrary ports to other users at different levels of permissions for how those ports can be shared. 2-3 major customers are already making workarounds for this missing feature, so we should build something first class to fit this need.

RFC

https://www.notion.so/coderhq/Shareable-Ports-4140e809958c457ba99f53b3e9ae1673?pvs=4

Related

• allow sharing a coder app or a port with specfic coder users #11201
• UX Improvement: Maximum port persistence configuration #10909
• Port is missing when port-forwarding via Dashboard #8189 :: This is a coder config issue
• Collaborate | Guest mode #8220
• bug: python ports showing in ports workspace UI when running Jupyter #10266
• UX Improvement: Port Sharing in the UI #10908

Action Items

Required

• Shared Ports: Add shared_ports enterprise feature key #11845
• Shared Ports: Add template option for maximum share level #11846
• Shared Ports: Edit MaxSharingLevel on template edit page #11847
• Shared Ports: make create API for shared ports #11849
• Shared Ports: make read API for shared ports #11850
• Shared Ports: Ensure Admins can edit port share level #11851
• Shared Ports: unshare shared ports when workspace goes dormant #11853
• Shared Ports: Enforce access control to ports using new shared ports #11854
• Shared Ports: Allow users to configure share access of ports on the workspace dashboard #11858
• support Internal server scheme setting for port sharing #12232
• Shared ports protocol switching is not instant #12454
• Control protocol on any port #12832
• Sharable Ports: Bring out of experimental #13058
• Documentation for Sharable Ports and Protocol selection  #13070

Reach

• Shared Ports: Control share level of ports in VS Code and code-server #11855
• Shared Ports: users can control share level from Jetbrains Gateway #11856
• Shared Ports: allow share level control of ports using the CLI #11857
• Shared Ports: share ports with specific users #12651
• Add option to hide ports from listening ports dialog #12722

[ericpaulsen]

adding this issue: #12232

[kylecarbs]

Minor bug: I can specify port 0 ;p

"Application port 1 is not permitted. Coder reserves ports less than 9 for internal use." is our error.

[kylecarbs]

It's not exactly clear to me why "Public" is greyed out here:

[stirby]

#12232 will be a requirement for this to make GA.

[stirby]

@kylecarbs the feature allows admins to restrict the maximum sharing level of ports in the template settings. If you're on our dev template the maximum sharing level is Authenticated.

We could add a tooltip if this is unclear.

[f0ssel]

Yup I was thinking a tooltip will fix that nicely

[matifali]

@kylecarbs the feature allows admins to restrict the maximum sharing level of ports in the template settings. If you're on our dev template the maximum sharing level is Authenticated.

Instead of the tooltip, we can also remove it from the dropdown if not allowed at the template level.

[bpmct]

I added two items to the checklist since we're still in experimental. I think there are some other dependencies too related to listening ports. Can you add those in so we have a good sense of what is blocking us from making this GA?

@f0ssel @stirby

[stirby]

Added #12832 since these are intertwined from a UX perspective.

[stirby]

@bpmct the list is complete. Added docs and GA issues.

[pauliuspetk]

@kylecarbs the feature allows admins to restrict the maximum sharing level of ports in the template settings. If you're on our dev template the maximum sharing level is Authenticated.

We could add a tooltip if this is unclear.

@stirby What do you mean by "If you're on our dev template"?

I'm on an OSS deployment, upgraded from v2.10.2 to v2.11.0 today, and am seeing the same thing as @kylecarbs: "public" option is greyed out.

In the workspace settings, the "Public" option is pre-selected and unmodifiable, as expected.

The documentation on port forwarding says:

OSS deployments allow all workspaces to share ports at both the authenticated and public levels.

I can't seem to find a way to enable public port sharing via the port helper.

[pauliuspetk]

I'd also like to suggest a simplification of the port sharing helper UI. I believe it's currently more confusing than it could be.

From the docs:

I'd suggest merging the detected ports section into the shared ports section, by simply pre-populating the shared ports section with the detected ports, and with the sharing level set to "Owner" by default, and the protocol set to HTTP by default, as that is essentially what happens when clicking on a detected port anyway.

This solves a few UX issues:

• it's not obvious that the detected ports are clickable;
• if you click on a detected port, it always uses HTTP, and you have to type in the port, select HTTPS, and click on the small icon should you want to override that;
• the "new window" icon itself is not immediately noticeable and not clear as to what it does, and there is no tooltip;
• for the above reason, the Share button next to the first detected port can be construed as "share the port I just typed in above"

If you just automatically add the detected ports to the shared ports with "HTTP" and "Owner" settings as defaults, and perhaps with some indication/separation on which ones were autodetected, the entire "Listening Ports" section could just go away.

I'd also suggest adding "new window" icon next to the port numbers in the list, to make it more obvious that they are clickable.

Here's a rough mockup of how all this could look like, for inspiration:

[matifali]

@coder/ts @coder/pms some good feedback here ⬆️

[BrunoQuaresma]

@matifali do you think we should open a ticket for redesigning this UI? I think having a ticket can give us time to try different alternatives and solutions based on user feedback and the opportunity to think about it more deeply.

[stirby]

@matifali @BrunoQuaresma We considered a design quite similar to this is one in the past and I like the consolidation. I'd like to review the mockups before we make a decision.

[BrunoQuaresma]

@stirby Sure, I think the first decision we have to make is if we want to spend some time working on the design before jumping into a fix/improvement. If yes, which I think we all agree, the person who creates the designs can share them with the team, including you and other PMs, to collect feedback and get approval. Wdyt?

[stirby]

Sounds good, moved to new issue.

[pauliuspetk]

Awesome! Looking forward to it.

@stirby could you please elaborate on #11486 (comment) ?

The observed behavior doesn't currently match what's stated in the docs...

[f0ssel]

Hey @pauliuspetk I can look into this behavior and get back to you, I think I understand from your description but want to investigate and see what is going on here to create this mismatch. Thanks for bringing this up.

[matifali]

@stirby a question about releases. When a feature is made GA in a release, which has a bug that is later fixed in main. Is it expected to backport the fix and patch the release?

For example, #13259 fixes the port sharing level, which was made GA in v2.11.0, but it still needs to be released as a patch.

[julianpoy]

Ran into that bug as well.