Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Allow serving apps at / #3378

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Tracked by #3516
ammario opened this issue Aug 3, 2022 · 8 comments
Closed
Tracked by #3516

Allow serving apps at / #3378

ammario opened this issue Aug 3, 2022 · 8 comments
Assignees
@Emyrk
Labels
api Area: HTTP API
Milestone
EE

Comments

@ammario
Copy link
Member

ammario commented Aug 3, 2022 •
edited by bpmct
Loading

Problem Statement

resource "coder_app" "code-server" {
  agent_id = coder_agent.main.id
  url      = "http://localhost:8080/?folder=/home/coder"
  icon     = "/icon/code.svg"
}

And then is accessed at a URL like https://dev.coder.com/@ammario/moria/apps/code-server.

While many web applications can be configured to serve at specific paths instead of root, it's not always obvious, possible, or convenient.

In these cases, an organization may prefer setting up a wildcard domain so their users can use apps at /. We should add this setting in coderd since it would likely be configured alongside the main access URL. A coder admin could set it to cdr.app and then requests for {agent_id}-{app_name}.cdr.app could forward to a particular app.

Definition of done

Users can access coder_app via a subdomain instead of a path

example schema:

resource "coder_app" "code-server" {
  agent_id = coder_agent.main.id
  url      = "http://localhost:8080/?folder=/home/coder"
  icon     = "/icon/code.svg"
+ relative = true
}

- # url is https://coder.example.com/@workspace/app
+ # url is https://workspace-app.coder.example.com/
@ammario ammario added the feature label Aug 3, 2022
@ammario ammario mentioned this issue Aug 3, 2022
Closed
@sreya sreya self-assigned this Aug 5, 2022
@bpmct bpmct mentioned this issue Aug 15, 2022
Closed
4 tasks
@misskniss
Copy link

Sounds like we have to better define what the API for this is going to look like, wildcard (domain, routing, etc), and some general discussion to be had before we can get started on this.
@spikecurtis @f0ssel @bpmct can we get a discussion or RFC going on this?

@bpmct
Copy link
Member

bpmct commented Aug 16, 2022

@spikecurtis brought up some notes from #2610

  • Cluster operator might not have a wildcard certificate / DNS entry as these are expensive

    This is sady a (time or $) cost the cluster operator has to pay if they want this feature. It's free with LetsEncrypt/ZeroSSL but costly in some enterprise/government scenarios.

    We have a (now closed proposal) RFC: Zero-config DevURLs #2986 which we could revive if we get a lot of feedback that people want a quick "tunnel" solution.

  • Certain apps seem to require this as indicated in the title

    We haven't come across an IDE where a path "required" yet, but requires a lot of tinkering and header manipulation to get things right. In v1, some didn't due to opinionated headers we set. Any app we have in our documentation should run on a path unless we explicitly say otherwise and link to an open issue.

  • Some apps can support both, but need to be correctly configured, e.g. RStudio according to @Emyrk

    👍🏼

  • Backend can probably accept either, simultaneously, but we still need to determine what URL to use on the front end

    Having it configurable by each coder_app in the template makes the most sense to me (down the road, a deployment-wide default could be added.

What do others think?

@ammario
Copy link
Member Author

ammario commented Aug 16, 2022

@bpmct

We have a (now closed proposal) #2986

The same people that have their networks chained by bureaucracy are unlikely to be able to use the solution proposed in that feature since it requires using our DNS and opens up their deployment to MITM attacks.

Backend can probably accept either

I think we need to support both automatically for each app to avoid breaking workflows. I also don't see a reason to disable one for the other.

@bpmct
Copy link
Member

bpmct commented Aug 16, 2022 •
edited
Loading

The same people that have their networks chained by bureaucracy are unlikely to be able to use the solution proposed in that feature since it requires using our DNS and opens up their deployment to MITM attacks.

Yeah for sure it would only help for small/trial deployments who really like web browsers and dislike setting up reverse proxies and certificates. There are other solutions though, such as Caddy's on-demand TLS + builtin via compose or something which are suitable for small deployments

I think we need to support both automatically for each app to avoid breaking workflows. I also don't see a reason to disable one for the other.

Yeah, it just comes down to where the link goes when the user clicks it from the dashboard (path or wildcard). I am suggesting we configure that via coder_app in the Template, but open to other ideas 🤷🏼

@ammario
Copy link
Member Author

ammario commented Aug 16, 2022

Yeah, it just comes down to where the link goes when the user clicks it from the dashboard (path or wildcard). I am suggesting we configure that via coder_app in the Template, but open to other ideas 🤷🏼

I suppose each app has to declare how it expects requests. I suppose if unspecified, it would prefer the wildcard?

@bpmct
Copy link
Member

bpmct commented Aug 16, 2022

Sure, as long as a wildcard is hooked up. 🤷🏼

@ammario
Copy link
Member Author

ammario commented Aug 16, 2022

Ugh. Well, the URL has to be stable. I wish there were a way to avoid extra configuration in the template.

@ammario ammario added this to the EE milestone Aug 22, 2022
@kylecarbs kylecarbs added api Area: HTTP API and removed needs grooming labels Aug 22, 2022
@sreya sreya assigned Emyrk and unassigned sreya Aug 25, 2022
@BrunoQuaresma
Copy link
Collaborator

Done in #3753

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Emyrk Emyrk

Labels
api Area: HTTP API
Projects
None yet
Milestone
EE
Development

No branches or pull requests
8 participants
@misskniss @BrunoQuaresma @sreya @Emyrk @tjcran @kylecarbs @ammario @bpmct