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. :slightly_smiling_face:

[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[bot]]

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)

:100: 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]

:100: 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"

:+1:

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" :slightly_smiling_face:

[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?

[gilesbutler]

I've been following along with this thread as I came to Gitpod looking for something similar. I've actually switched to GH Codespaces now but thought I'd share my setup on how I got a custom domain / stable URL working with Gitpod and Cloudflare. Hopefully it helps others.

I created node script called dev-server-redirect.js which contains the following...

const { exec } = require("child_process");
const CloudflarePageRules = require('cloudflare-page-rules');

// Setup CloudFlare SDK...
const cloudflare = new CloudflarePageRules(process.env.CLOUDFLARE_TOKEN);

const devServerPort = 8081;

// Get our workspaces url...
exec("gp url", async (error, stdout, stderr) => {
    if (error) {
        console.log(`error: ${error.message}`);
        return;
    }
    if (stderr) {
        console.log(`stderr: ${stderr}`);
        return;
    }

    // Get the dev environment url and remove hidden line breaks...
    let url = stdout.replace(/(\r\n|\n|\r)/gm, "");

    // Prepend the dev server's port...
    url = url.replace('https://', `https://${devServerPort}-`);

    // Append the url params so CloudFlare passes them through correctly...
    url = url + "/$1";

    try {
        const result = await cloudflare.edit(process.env.CLOUDFLARE_PAGE_RULE_ID, {
            "targets": [
                {
                    "target": "url",
                    "constraint": {
                        "operator": "matches",
                        "value": `${process.env.CLOUDFLARE_CUSTOM_DOMAIN}\/*`
                    }
                }
            ],
            "actions": [
                {
                    "id": "forwarding_url",
                    "value":
                        {
                        url,
                        "status_code": 302
                    }

                }
            ]
        }, process.env.CLOUDFLARE_ZONE_ID);

        if (result.success) console.log(`CloudFlare Page Rule updated with ${url}`);
    } catch (error) {
        console.log(error);
    }
});

It essentially grabs the dev environment's current url and updates a Page Rule on Cloudflare to manage the redirection for the custom domain / stable url.

I ran this script each time the environment started so it auto updated for me.

It worked well for what I needed so hopefully it can be an interim solution for others.

Thanks

[svenefftinge]

We should also consider if static IPs are important to support in addition or alternatively. It has been discussed here, but I'd like to discuss this in this context. So I'm closing it.

[atduarte]

Something like |team|-|project|-|port|-|username|.ws.gitpod.io should work.

That seems reasonable. I'm just concerned with two things:

1. the edge case of having multiple workspaces of the same project, as the requirement is not met in those cases (i.e. it breaks), but can't really think of a better option.
2. the URL is stable for the individual and not for the whole team which requires additional steps from users (e.g. configure env. vars with their API keys). The only way I see to mitigate that is by defining local urls: the local companion app could automatically define an entry for |team|-|project|-|port|.gitpod.local.

We should also consider if static IPs

The problem we are solving with the static IPs seems somewhat different: We want to avoid having to reconfigure some firewalls with whatever IP is being used by the workspace(s).

To solve that, and thinking that this might be relevant to companies using Gitpod SaaS, we could add a "Static External IPs" option for teams. When selected, one or multiple IP addresses would be shown and those addresses would be exclusively and always used by the prebuilds and workspaces of that team.

[akosyakov]

Another place where I think stable URLs would help with a conjunction of own DNS server on client side: https://github.com/gitpod-io/gitpod/issues/5306

[atduarte]

We discussed this internally and we constantly go back to the fact that this problem is not entirely solvable as long as the URL is globally defined (because of conflicts of multiple running workspaces).

We could for example assign a pool of URLs to a given project to be used to configure third-party callback URLs settings that don't support wildcards, but it would be a complex flow and wouldn't solve the iframe/JIRA problem @leipert is having.

---

💡 Would it be possible to use the browser extension as a proxy, and tightly integrate with the Gitpod app?

I'm thinking something like: (1) having an option in the workspaces list and IDE to "Set local URL...", (2) user inputs string into a textbox, (3) browser extension would proxy {chosen-string}-{port}.gitpod.local to the usual workspace url. If the browser extension is not installed the user is invited to install it.

Locally the user could do something similar (functionally-wise) via VS code extension or CLI.

[akosyakov]

Would it be possible to use the browser extension as a proxy, and tightly integrate with the Gitpod app?

I don't think so, we are talking about integrating in 3rd party services which don't use the browser or cannot install any apps in own infrastructure. If it would be the case one can just use localhost via the local companion. An idea that it should work on Internet without extra.

[atduarte]

@akosyakov maybe we are thinking about different issues. I'm assuming these URLs don't need to be publicly available and they can be defined in any domain (i.e. gitpod.local) as long as they are stable. Are those assumptions incorrect?

[atduarte]

In order to move this forward faster, @akosyakov and I jumped on a call to talk about this. Notes:

• The local companion app should solve the issue of non-stable URLs since ports become accessible at localhost:{port} as it's normal in local development.
• Currently, we are still improving and stabilizing the local companion app. Documentation needs to be written also.
• Concluded that probably the best path forward is investing in making the process of using the local companion app for this use case as seamless as possible. For example, by making it run as a daemon—which in fact is already planned to happen.

Although, if we understood correctly, @gilesbutler's use case might not be solved by this. @gilesbutler could you please share with us more details? Particularly whether you were looking to have a stable URL that is globally available on the internet and, if that's the case, why?

In the meantime, anyone feeling adventurous may try our preview release of the local companion app following the steps detailed here. :)

[simsim2006]

Hi guys,

I don't know if it would be the best place to give feedback about this feature request: support for multi tenant application url. I explain myself:

I sell my saas software to big companies, where multiple end users (employees of those companies) are sharing the same environment. Each of those environments have some separation logic (eg: 1 database per customer). Each of those environments are also accessible via a custom sub domain, eg: cocacola.mysaasapplication.com and pepsi.mysaasapplication.com

As we want to be closer to our production settings, on our stage environment and local environment, we can reproduce the same behavior. For example, my stage urls look like this: {mybranchname}-{customername}.stage.mysaasapplication.io. So 2547-newfeature-cocacola.stage.mysaasapplication.io & 2547-newfeature-pepsi.stage.mysaasapplication.io would be executing with the same code, but with different databases.

Depending on how you tackle the stable url issue, would be nice to be able to add such information in url. We are also using Auth0 which requires me to whitelist callback url. As wildcard is allowed in Auth0, we could wildcard *.gitpod.io as callback url, but that's not secured. But for instance, if you allow custom domainS on NON self hosting gitpot, this could solve both of my issues.

This would be for example: {gitpod_namespace}.{customername}.mysaasapplication.dev. I can then whitelist on Auth0 side for all domains matching *.mysaasapplication.dev (provided that the wildcard works for subdomain and subsubdomains), then i can still extract my customername value in my application logic, and gitpod can still generate dynamically its instance name etc

[atduarte]

Given the impossibility of having truly stable and global URLs, because we may potentially have multiple users and workspaces of the same project running at a given moment, my suggestion is that we continue focused on improving the local companion app (e.g. making it run as daemon) and close this issue.

Using the local companion app, it's possible to use localhost and define additional local URLs (modifying /etc/hosts) as if we were developing locally solving all associated issues.

If you have a different point of view or conflicting use case, please do share!

[ctrlaltdylan]

@atduarte while the routing of ports to localhost with the local companion app is a big improvement - how is one supposed to use HTTPS in conjunction with localhost?

ngrok seems to be the only alternative at the moment, but you're limited with the number of ports that can be signed.

Some development needs to be in HTTPs, like anything involving use of webcams, OAuth security restrictions, iframe security restrictions. It's just good practice.

Any plans to support this in the future?

[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.