Support stable URLs for endpoints

[codemzy]

Hey gitpod team,

I'm on the premium plan and using one of my workspaces for development work on a repo. I've proxied a url e.g. dev.my-url.com to the url of the exposed port when I'm running the site so I can preview the work on my domain url (because some services I use the api keys are tied to the url) and also I can remember it then etc.

Anyway, this has been working fine, but today I opened the workspace and ran the site on the port, but it seems the workplace url has changed. Is this something that is expected? As in the same workspace may have a different url? I've not created a new workspace from the same repo or anything like that. I can reset up the proxy to the new url, but I would rather not have to keep doing this if it can be avoided. I expect to be working on this project for a few months.

Thanks 😄

[svenefftinge]

Workspace urls are not meant to be stable, as they depend on the cluster they are running in. You can always look up the URL by running

gp url <port>

Would it be possible to have your proxy accepting this information on some endpoint? That way you could update the proxy whenever you start a workspace and you could even easily start fresh workspaces on your repo all the time, which is how Gitpod is intended to be used.

[geropl]

Thanks @codemzy for sharing your usecase! I think this is an excellent point for adding a "URL" feature to Gitpod. 🙂

[devops-at-alinea]

I use Auth0 to handle logins. Authorized login urls need to be defined in my Auth0 dashboard or via an admin api.

Using the admin api just heaps extra complexity on my dev environment (and means I have to strip this code out in production) - the management of live and unused urls via the api would not be trivial either.

I've learned to double check my workspace url whenever I get a service error page from Auth0 now and update my live urls in Auth0 dashboard.

However I can see this issue become more critical as I use more 3rd party services with webhooks/authorized urls etc.

[codemzy]

Workspace urls are not meant to be stable, as they depend on the cluster they are running in. You can always look up the URL by running

gp url <port>

Would it be possible to have your proxy accepting this information on some endpoint? That way you could update the proxy whenever you start a workspace and you could even easily start fresh workspaces on your repo all the time, which is how Gitpod is intended to be used.

I don't think this would be possible, I set up the proxy from my netlify production deploy in the _redirects configuration, so while it is something I can easily update, I don't think it's something I could easily automate.

Maybe I'm not using gitpod how it was intended, by I usually need my dev environment for at least a few weeks at a time while I work on adding a feature or working on a new project, so it would really handy if each workspace could have a static url that doesn't change for the lifetime of the workspace. Especially useful when you have to authorise your api keys against a URL on other services you are using during development.

Please consider this! 🙏 🌟

[svenefftinge]

Please consider this! 🙏 🌟

Sure, we are thinking about a solution. Thank you for sharing your use cases.

[MeStrak]

I also have the same Auth0 challenge as @devops-at-alinea - a stable endpoint would be very helpful so I don't have to update the Auth0 dashboard all the time.

I think that wildcards can be specified for subdomains in the Auth0 dashboard, so it there was a way to have the project name in the subdomain it might solve the need.

For example:
https://xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxx.myprojectidentifier.ws-eu03.gitpod.io/
OR with a hyphen
https://xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxx-myprojectidentifier.ws-eu03.gitpod.io/

Where myprojectidentifier is some combination of project/username (would need some thinking about).

Within Auth0 I could allow the callback url https://*.myprojectidentifier.ws-eu03.gitpod.ioor https://*-myprojectidentifier.ws-eu03.gitpod.io respectively for the two cases above.

According to their docs I think that would work: https://auth0.com/docs/applications/wildcards-for-subdomains. As a guess maybe the hyphen option would be easier to implement because no additional sub domain level would be required?

[svenefftinge]

I have created an example for Auth0 https://github.com/gitpod-io/auth0-express-webapp-sample

[MeStrak]

Thanks @svenefftinge!

That's what I've done - the other suggestion was to be slightly more secure by limiting to the project identifier but actually it doesn't really matter for the dev environment anyway.

[leipert]

Another use case, @svenefftinge, at GitLab we want to use it to develop integrations with the Jira Cloud Platform. A changing URL means updating the URLs inside of Jira every time you restart a pod. The linking happens via an iframe.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[akosyakov]

We just announced preview version of Gitpod local companion which allows to tunnel any tcp port: https://www.gitpod.io/blog/local-app particularly it allows you access everything on localhost on proper port, similarly how you will do it in the local env, please try and give us feedback 🙏🏻

[svenefftinge]

Another solution is to use https://ngrok.com/docs

[csweichel]

One key question to answer here is how that stable URL gets assigned to a workspace? What if I have two workspaces open?

[csweichel]

From Slack:

@geropl
Some thoughts on the actual "redirector":

• |name|.|userId|.gitpod.io won't work because we need to limit ourselves to one level of wildcards (because of certificates)
• using meta/"proxy" for this is not nice for tying workspace-bound connections to it (again)
• the only reason we need "meta" is for the "name" -> "workspace" mapping
• (authentication is done by ws-proxy anyway)
• one could think about:
  • have an endpoint on /api/ws-name-mapping that on GET stores a cookie containing the current mappings
  • have a completely decoupled "redirector" component that could be deployed anywhere; for instance under

@csweichel

|name|.|userId|.gitpod.io won’t work because we need to limit ourselves to one level of wildcards (because of certificates)

💯 how about .ws.gitpod.io?

using meta/“proxy” for this is not nice for tying workspace-bound connections to it (again)

indeed, this would introduce some level of connection. However, I don’t think it would be stronger than what we have right now, because it would very much be based on the IDE URL that we already rely on from the meta side.
It would introduce a “failure coupling” though where if meta goes down the redirector fails.
the only reason we need “meta” is for the “name” -> “workspace” mapping
We could also consider transferring this to the workspace side and remove meta from the equation altogether.

have an endpoint on /api/ws-name-mapping that on GET stores a cookie containing the current mappings

Downside of this approach is that you need cookies available/set for the redirect to work. For API calls/curl that won’t be the case.

have a completely decoupled “redirector” component that could be deployed anywhere; for instance under |name|.names.gitpod.io

Could certainly be its own component, but it would still need to run in either meta or workspace. I don’t think the operational overheard of introducing something outside of those two structures is worth it right now.

[geropl]

💯 how about .ws.gitpod.io?

We could also consider transferring this to the workspace side and remove meta from the equation altogether.

Both contradict each other, no? I thought getting rid of the ws part was one of the requirements (cluster independence).

However, I don’t think it would be stronger than what we have right now, because it would very much be based on the IDE URL that we already rely on from the meta side.

Not sure what you mean with this. What I implied above is that we want to have an "internal redirect" which is transparent to browsers - hence the strong connection. The reasons I thought this is a requirement was to support all kind of clients scenarios.

But it might make sense to go through those use-cases one-by-one and make sure they are important enough to warrant that complexity. If we would have a "simple redirect" (302) the implementation is far easier indeed.

[csweichel]

💯 how about .ws.gitpod.io?

We could also consider transferring this to the workspace side and remove meta from the equation altogether.

Both contradict each other, no? I thought getting rid of the ws part was one of the requirements (cluster independence).

It would just be ws, not ws-eu and hence independent of the region. Basically I wasn't too fond of the names segment and figured that ws is closer to home.

However, I don’t think it would be stronger than what we have right now, because it would very much be based on the IDE URL that we already rely on from the meta side.

Not sure what you mean with this. What I implied above is that we want to have an "internal redirect" which is transparent to browsers - hence the strong connection. The reasons I thought this is a requirement was to support all kind of clients scenarios.

But it might make sense to go through those use-cases one-by-one and make sure they are important enough to warrant that complexity. If we would have a "simple redirect" (302) the implementation is far easier indeed.

I reckon we should avoid to actually tunnel traffic through the "redirector". That would

• incur considerable network load,
• increase cross-cluster egress cost,
• too tightly couple meta/workspace.

If we combined the simple redirect with CNAME DNS entries, we'd also make this work for clients that don't cope with redirects. We would also open the door for weird DNS-caused failure modes (e.g. cached DNS entries pointing to the wrong workspace).

[geropl]

It would just be ws, not ws-eu and hence independent of the region. Basically I wasn't too fond of the names segment and figured that ws is closer to home.

Got it, completely d'accord.

I reckon we should avoid to actually tunnel traffic through the "redirector"

👍

If we combined the simple redirect with CNAME DNS entries

That would be nice indeed! And would nicely match the semantics as we're offering a "name service" 🙂

[csweichel]

Awesome - happy to find consensus on the technical side :)

We still need to answer a bunch of questions around the stable name itself:

• how does that name come to be? Is it computed based on the repo/context URL - and/or can users choose it?
• what happens if you start multiple workspaces that would want the same URL?
• how do we handle name clashes with other workspaces that might end up on the same "stable URL", esp. if users can influence that URL?

[codemzy]

Could it have the username or a unique string assigned to each user in the url? E.g. |userId|-|custom-url|.ws.gitpod.io and assuming stable urls will be a premium feature (e.g. on the paid plans) you get a random url how it is now as standard, and maybe the user could optionally assign the stable url (e.g. the custom url part of it). If they try to assign a stable url that they are already using, it blocks it. (Like on github if you try to assign a repo with the same name it tells you that you can't).

Although to be honest, for my original use case I think how things are good now. The workspace name carries over the url, e.g. the workspace name red-penguin-random becomes https://[port]-red-penguin-random.ws-eu11.gitpod.io/ so I can proxy a custom domain (e.g. dev.domain.com) to that. If I get rid of a workspace and create a new one from the same repo, I don't expect the url to stay the same. The issue I had before was that the workplace url might change day to day. I don't think this happens anymore (although I may be wrong and I can't speak for other use cases!).

[geropl]

So far I thought about this as a way to expose a workspace, so there's always a 1-1 connection between "stable name/URL" and "workspace". Following this |workspaceId|.ws.gitpod.io is the simplest solution that avoids most of the mention problems (name clashes).

Everything else - especially custom names (with possible per-user namespace) - would be an addon and could be handled atop of this.

[codemzy]

So far I thought about this as a way to expose a workspace, so there's always a 1-1 connection between "stable name/URL" and "workspace". Following this |workspaceId|.ws.gitpod.io is the simplest solution that avoids most of the mention problems (name clashes).

Everything else - especially custom names (with possible per-user namespace) - would be an addon and could be handled atop of this.

That would work great for my needs. Even if you still include the port in the url |workspaceId|-|port|.ws.gitpod.io to allow for different ports to be used.

[svenefftinge]

how does that name come to be? Is it computed based on the repo/context URL - and/or can users choose it?

We should not include workspace names, because they are ephemeral. Instead, we should use a combination of project and user.
Something like |team|-|project|-|port|-|username|.ws.gitpod.io should work.

what happens if you start multiple workspaces that would want the same URL?

We should surface the public URLs in the ports view.
When not available we can assign a different one (e.g. add a number to the end) or indicate that it is taken already.

how do we handle name clashes with other workspaces that might end up on the same "stable URL", esp. if users can influence that URL?

This would not be possible with the proposal above. Do we know a use case for "user influenced" URLs?

[axonasif]

Seen several people asking for this on our discord server, one recent query: https://discord.com/channels/816244985187008514/952289368394043412/952601245598752808

[raphaeltm]

I was asked to add my use case to this issue, so here it is. Part of our system is dependent on webhooks and code running on a third party service. In a traditional (not web based) dev environment we used to use a tunneling tool (like ngrok) to manage traffic from those, but with gitpod already being on the web, it would make a lot of sense to be able to provide a stable gitpod url instead.

[raphaeltm]

A bit more on how I would imagine this feature working:

It would be great to be able to assign a subdomain to a project, per user. Something like <username>-<project-name>-<user-selected-name>.ws-us.gitpod.io. The selected subdomain would be assigned to a port. If a workspace is launched for the project, that subdomain would point to it. If a second workspace is launched for that project by the same user, the launch would either error out, or provide a message to the user saying that the subdomain is already pointing to a different workspace.

One detail I would add from previous experience: if possible, it would be nice to have multiple subdomains point to the same port. Like that we can choose to use our own proxy to manage traffic based on hostnames.

[geropl]

@jldec This is a feature request that won't go away - we should make we keep it on our radar, even if not working on it immediately. I filed it under "Projects Usability", but feel free to re-assign.

[nassimm]

Hi,
Having a subdomain would allow our team to use gitpod, as we could whitelist our auth provider that only allows for a simple wildcard on subdomains.
The local companion works, but using it with multiple workspaces means additional local configuration to route the ports correctly, which I think is detrimental to one of the benefit gitpod brings in the first place: having all of the dev environment 100% described in code. (I've already had trouble getting non-random ports on windows for the companion, with no issue on linux and mac)

Thanks 👍

[jldec]

cloudflared tunnels may be another option, especially if you already use Cloudflare DNS.

I was able to start a quick tunnel following the Cloudflare docs.

I have not tried this, but would expect that you could configure a stable subdomain per user in cloudflare DNS this way.
https://developers.cloudflare.com/cloudflare-one/tutorials/share-new-site/#create-dns-records

[axonasif]

I have not tried this, but would expect that you could configure a stable subdomain per user in cloudflare DNS this way.
https://developers.cloudflare.com/cloudflare-one/tutorials/share-new-site/#create-dns-records

@jldec I had done this inside Gitpod while trying out some minecraft server dev and it works 💪
But it might be HTTP only. To connect to my minecraft server I had to use cloudflared client on my local device to connect to the tunnel, which would forward the ports and I could then connect to it by localhost:port.

[raphaeltm]

cloudflared tunnels may be another option, especially if you already use Cloudflare DNS.

I was able to start a quick tunnel following the Cloudflare docs.

I have not tried this, but would expect that you could configure a stable subdomain per user in cloudflare DNS this way. https://developers.cloudflare.com/cloudflare-one/tutorials/share-new-site/#create-dns-records

Yup, this works. cloudflared is what we have been using.

[loujaybee]

A similar related use-case from discussion with a user today (@konne) was around security, that the current URL process with the organisation and the repo exposes information (when the link is shared), and the user would like the ability to mask the URL by updating or renaming a workspace URL. However, this might be sufficiently different to warrant it's own issue, but that depends on the implementation.

[atduarte]

What if 💡 we introduced a gp subdomain [name] command that created a stable and namespaced url in a proxy. The url would be namespaced by the team+project when the workspace is from a project, and the workspace owner is a member of that team. Otherwise, the url would be namespaced by the user. Don't think we have a unique "short" string per user, but could easily create it.

For example, if I executed gp subdomain "random" in a gitpod project workspace, since I'm part of the team, I would get and be able to use 8080-gitpod-gitpod-random.proxy.gitpod.io. Non-members, would get something like 8080-u-f8qwe8-random.proxy.gitpod.io where f8qwe8 is the generated sticky username of the user.

The command should warn and ask for confirmation in case there's already active usage from another workspace instance. But to allow this to be used programatically (e.g. in the .gitpod.yml), we would want to have a --override option.

It would also be nice that on restart, it automatically tried to register the previous existing entries.

Insane? Maybe. Let me know 😅 Also have no idea how difficult this would be to implement 🤔

[csweichel]

Stable URLs is a repeated request, either generated (your proposal), or even manually set. Two key issues with stable URLs remain:

• they are an exclusive resource, hence cannot be re-used across multiple workspaces on the same context (whichever determines the stable URL)
• proxying off a central place introduces a new dependency between application and workspace clusters which comes at the expense of traffic cost ($) and stability/a new failure mode. For HTTP we could just redirect, but for SSH AFAIK no such mode exists.

[konne]

@csweichel one question, can this not be done via DNS aliases.
In general I expect a refresh period of 5mins would be for both sides acceptable.

[devops-at-alinea]

I was doing this via https://ngrok.com/.

I had a number of domains e.g mysite1.eu.ngrok.io, mysite2.eu.ngrok.io etc setup in ngrok.
These were also set in gitpod as variables e.g NGROK_DOMAIN =mysite1.eu.ngrok.io as was the NGROK_AUTH_TOKEN.

My .gitpod.yml had this in it:

tasks:
- init: >
    wget https://bin.equinox.io/c/4VmDzA7iaHb/ngrok-stable-linux-amd64.zip 
    && unzip ngrok-stable-linux-amd64.zip 
    && rm -f ./ngrok-stable-linux-amd64.zip
  command: >
    if [ -z "$NGROK_DOMAIN" ]; then echo "\n\nNGROK_DOMAIN is not set\n"; else gp await-port 4040 && gp preview $NGROK_DOMAIN; fi
    && printf "\n\nThis window can be closed\n"  
  #ngrok
- name: ngrok
  command: >
    while [ ! -f ./ngrok ]; do sleep 1; done
    && if [ -z "$NGROK_DOMAIN" ]; then echo "NGROK_DOMAIN is not set, skipping ngrok setup" && exit 0; fi
    && ./ngrok authtoken $NGROK_AUTH_TOKEN
    && gp await-port 8080
    && ./ngrok http -region=eu -hostname=$NGROK_DOMAIN 8080

This used to work very well - but now something has changed in gitpod and whenever I run ngrok the workspace just closes down.

[atduarte]

@csweichel I guess having HTTP only would solve most cases, and be a good 🛹.

[LaCocoRoco]

For OAuth2 Redirect Callback is necessary.
As suggested in this Issues i started to use cloudflare.
Is currently any other/better way to handle this problem?

tasks:
  - name: cloudflared
    command: |
      sudo wget -q https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
      sudo dpkg -i cloudflared-linux-amd64.deb
      sudo rm cloudflared-linux-amd64.deb
      sudo cloudflared service install $CLOUDFLARED
      exit

[jmls]

For OAuth2 Redirect Callback is necessary. As suggested in this Issues i started to use cloudflare. Is currently any other/better way to handle this problem?

tasks:
  - name: cloudflared
    command: |
      sudo wget -q https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
      sudo dpkg -i cloudflared-linux-amd64.deb
      sudo rm cloudflared-linux-amd64.deb
      sudo cloudflared service install $CLOUDFLARED
      exit

are you able to get oauth2 callback working like this without installing something locally ? If so, would you let me know how you did it ? :)

[LaCocoRoco]

@jmls No, i couldn't find a way.

[pascuflow]

Still no way to do this? Have too many webhooks and microservices that can't just be spun up with on the fly dynamic urls.

[arel]

First of all, I love gitpod, and I've been a paying customer. But, if there is one reason I will stop using it, it is this issue.

To add my use-case to this issue:

• our company relies on ChromeOS, which is intentionally locked down and makes it impractical or impossible to use the local companion app and other workarounds.
• whenever the URL unpredictably changes, all local state in apps we are developing is effectively lost with no warning (e.g., saved passwords in the browser to everything in localStorage). This causes us to lose data and time (for instance, saved GraphQL queries that are being tested in GraphQL Playground.)
• worse, data loss can happen unpredictably and completely outside the control of the developer (e.g., when a workspace times-out and is reloaded).

[jmls]

is this still an issue or is there now some super option that permits a stable url ? :)

[arel]

GitPod has not prioritized, or even seems to care about, this fundamental flaw. I stopped subscribing a long time ago and moved on.