I'll defer to@sreya and@kylecarbs on the token scoping. From a product POV, supporting the following as a first iteration seems solid:

coder.mydomain.com# host*.coder.mydomain.com# subdomains for apps

We can open another issue "Run Coder apps on a separate domain" as some users may eventually want

coder.mydomain.com*.different-coder-apps-domain.com

(We have a few Coder Classic customers who do this today for security reasons)

(We have a few Coder Classic customers who do this today for security reasons)

Yes, it's more secure to run from another domain. I think we will want to implement some sort of toggle on the BE to block the same domain in the future.

Awesome on first iteration though 👍. For now, I think I'll just throw a cookie on both.domain anddomain to handle this. We will need to tighten security in future.

For named applications, will this PR make therelative_path property for coder_app function as expected? (e.g. links from to apps from the web UI will go to the subdomain)

For named applications, will this PR make therelative_path property for coder_app function as expected? (e.g. links from to apps from the web UI will go to the subdomain)

It will not. The deployment still needs to setup their certs with wildcards to support this feature. Sorelative_path still requires some deployment side config. We need to figure out how to go about displaying this 🤔

The subdomain url will work, but the FE still has the path based link

@Emyrk since oursession_token is HTTPOnly, is there any way to steal the cookie even with a malicious application? I'm thinking no, but I'm not sure.

@Emyrk since oursession_token is HTTPOnly, is there any way to steal the cookie even with a malicious application? I'm thinking no, but I'm not sure.

We also strip the session token header on the proxy as well, correct?

@Emyrk since oursession_token is HTTPOnly, is there any way to steal the cookie even with a malicious application? I'm thinking no, but I'm not sure.

We strip the cookie in the proxy app:

There is something you can do though with a malicious app. You can send authenticated requests to coderd. This is an issue I put in the description. We should not allow sharing apps until we close that

@deansheather right now, I'm doing this in the FE:

# Subdomain`${port}--${agentName}--${workspaceName}--${username}.dev.coder.com`# Subpath`https://dev.coder.com/@${username}/${workspaceName}/apps/${port}`

Is that right?

Yes@BrunoQuaresma, but the subpath should be/@$username/$workspace.$agent/apps/$port. The port is also interchangeable with an application name in both cases

It seems like we'll need to add a server-side option for the wildcard path so we can redirect users on the frontend properly, or we could assume a wildcard above the root, but we'd just have to document that.

@kylecarbs this PR only does wildcards underneath the site--access-url (i.e.dev.coder.com =>app--agent--ws--user.dev.coder.com), and not if the access URL is an IP address as that's obviously not supported.

In a future PR when we implement proper devurl auth (with their own tokens, similar to v1) we will be able to support separate domains, and it'll be configurable through a separate--devurl-domain flag or something.

This PR is the MVP for hostname based routing

@bpmct the env var can be temporary until we do the changes I said in my above comment. I'll add a check for the env var

Actually@bpmct that's a build time env var, not a proper one. I'm just going to merge this as is and we can figure out what we want to do about it when we solve the devurl auth problem

@kylecarbs Bruno is working on this in a separate frontend PR. He will be reading that value to figure out whether to link to wildcard or path-based route.

@kylecarbs here is the related PR#3812