Nice to see that this is now further developed. I ask a long time ago Coder support for this!

In the mean time we are using a simple ingress to bypass coder completely as it was not flexible enough.

Our UseCase was to Develop WebComponents in a Coder Workspace which then gets included into a deployed web portal. This was not possible due CORS issues.

Our UseCase was to Develop WebComponents in a Coder Workspace which then gets included into a deployed web portal. This was not possible due CORS issues.

That use case would still not work even under the new proposal. The CORs handling is only between workspace apps. It still would block requests that are exiting Coder.

CoderVPN can be helpful here, in that you can directly interact with a web app on your workspace and set whatever CORS policy you'd like on it.

The implementation cannot be configured at the workspace, template, or user level. To be configured there, an in memory cache would be required.

The requirements to a solution cannot require a database lookup on each request. That would cause too many database calls for web apps with hundreds of static resources.

I agree we can't do a DB lookup on each request, but I think a per-workspace policy cache would give acceptable performance. It adds complexity, which needs to be balanced against the utility of configuration at workspace, template, or user scope.

@spikecurtis yes. I was thinking either per workspace or per template.

I wonder too if request cookie headers come across in CORS pre-flight requests. If so, we have a cookie on all subdomain apps (that are not public), that define the app. It looks like this inside a jwt. I just realized you need to auth to the subdomain first to have the cookie set. So this only works if the user visits the subdomain first. And this breaks even more if an external app from outside a browser context hits the app (assuming it is public)

  "request": {
    "access_method": "subdomain",
    "base_path": "/",
    "app_prefix": "",
    "username_or_id": "emyrk",
    "workspace_name_or_id": "april",
    "agent_name_or_id": "dev",
    "app_slug_or_port": "filebrowser"
    # CORS level here?
  },

We could maybe define it on the app level, if the app is not public (or we set this cookie regardless of auth?). We sign it with a local key, so forging a cookie is not possible.

@MrPeacockNLB to confirm, is that web portal external to Coder? And is that web portal static?

What sort of CORS policy is required for your functionality? Access-Control-Allow-Origin: *? Or is it specific domain(s) known in advance? Access-Control-Allow-Origin: https://some.domain.com?

Including some more information from another user. They have a use case to use a Coder app as the API service for some external service.

When dealing with external services, we can either support some static list, or we will have to defer to the application. I do not see a way to implement a dynamic filter in any sensible way.

Maybe if we configure this specific to an app, a workspace, or a template, we have an option to not strip the original CORS headers. Just pass through whatever the app does by default.

CoderVPN can be helpful here, in that you can directly interact with a web app on your workspace and set whatever CORS policy you'd like on it.

This might not work for all use cases. One reported use case is to make requests to the Coder app from some external site/server. So the user is not in the equation at all. A VPN would only expose apps to other localhost servers. This is only made possible because share level public is a thing. So no auth is required.

One reported use case is to make requests to the Coder app from some external site/server. So the user is not in the equation at all. A VPN would only expose apps to other localhost servers. This is only made possible because share level public is a thing. So no auth is required.

CoderVPN allows access to the Coder workspace app at the DNS name <workspace>.coder, so it would be accessible from an external site/server if the right CORS policy is configured on the app. Coder is not involved at the HTTP layer at all in this case, so the developer who is working on the app can set their own CORS policy. It's only accessible to the user that owns the workspace tho.

If the goal is to make a public application via Coder, then you'd need to use the Coder proxy or set up some other way to do ingress into the workspace.

If the goal is to make a public application via Coder, then you'd need to use the Coder proxy or set up some other way to do ingress into the workspace.

Yup this.

I am wondering if we can just detect an existing CORS header, and if present, do not strip or append our own. This would require us to pass the preflight request to the app, then modify the response if it omits the headers.

I'm in favor of solution 3 if we can do it at the template level. One disadvantage of the app level is it does not allow shared ports or any ports to be used.

If we did it deployment-wide, it would probably break many use cases.

@mtojek @johnstcn Is this also something 🥥 can take?

@bpmct I wonder if we can Solution 3 Disable based on response headers. Just disable if the headers are already set.

@mtojek @johnstcn Is this also something 🥥 can take?

🥥 is on it!

I wonder if we can Solution 3 Disable based on response headers. Just disable if the headers are already set.

We would still need to rewrite the header if they set Access-Control-Allow-Origin: * on a non-public port, right?

I wonder if we can Solution 3 Disable based on response headers. Just disable if the headers are already set.

We would still need to rewrite the header if they set Access-Control-Allow-Origin: * on a non-public port, right?

If we decide not to, then the app can never have a cross origin request because credentials will never be included. But we could let it be their mistake, although the solution is a bit nuanced because it requires knowing you need the Coder cookie for access. Would be amazing if we could return some error message in the preflight response. But that requires us to basically anticipate a CORS error based on the user_agent and other headers 😢.

Solution 3 is the most basic, but it is the most transparent and hard to debug. I don't think we can even add any headers to attach meta data on the behavior, because CORS has to whitelist headers (if not using Access-Control-Allow-Headers: *)

Chat with @dannykopping @johnstcn summary.

Add the CORS configurable behavior on this cookie jwt:

CORS behavior should be configurable on the app section in terraform.

An idea: the CORS behavior could be configurable by some enum in terraform on the app:

CORS Enum:

• cors_behavior: 'user/deployment/global/passthrough' (TBD all naming)

To be clear, we're opting for Solution 3 :: Disable at the app level.

We're going to allow template authors to optionally enable passthru of all CORS requests to the "upstream" app, which will be solely responsible for responding to those requests; coderd will only be responsible for authentication based on the app token provided in the cookie and proxying the requests/responses on.

Will this also work with shared (or non-shared) ports that are NOT coder_apps? The reason I was in favor of template-level is that many template authors will not be aware of which ports developers are using.

@bpmct I do not think the current solution does. We'd have to also add it as a column on the shared ports table, and make some ui element for the toggle?

@bpmct how do you see this being defined at a template level? As a toggle in the UI only, or via some terraform as well?
I'm not sure which resource this would fit into, unless I'm missing something obvious?

Or do we instead allow the user to configure CORS handling at the last moment of responsibility when they actually share a port?

--

As an aside, and please forgive my ignorance, did we ever consider adding shared ports as a top-level terraform resource, or is it expected that folks created a coder_app for those? i.e. if a webserver is installed on the workspace and it needs to be accessible, should the workspace owner manually make that port shared OR create a coder_app? Are those the only two options?

@bpmct that's the workspace view; did you perhaps share the wrong image? I assume you want this set as a policy for all workspaces using a template.

@bpmct @Emyrk something like this perhaps?

I like that! Legit perfect.

@bpmct that's the workspace view; did you perhaps share the wrong image? I assume you want this set as a policy for all workspaces using a template.

Ah my image was just showing the ports dropdown and how it is different from coder_app and important to support. I agree the config should be template-level like your screenshot

@dannykopping that is on the template level, however I thought it was discussed to implement it per-app. Meaning it would have to be on the port sharing drop down somehow.

If we make this template level, then all apps share the same CORs behavior. In the use cases described, I think it's preferred to have a singular app be exempt, but other apps keep the nice default behavior.

@Emyrk I think it's a case of AND rather than OR, based on what @bpmct said here - no?

@Emyrk I think it's a case of AND rather than OR, based on what @bpmct said here - no?

Ah. It just feels a bit strange to assert at the template level for all ports imo. Per app makes sense, but to apply at the template level means users are going to have to send us their template CORS setting when submitting issues. It just feels disconnected from what it is actually affecting.

The only requirement from the product side is that we also support this for both coder_apps AND the ports dropdown since I imagine 80% of users will use the URLs from the ports dropdown (non-named coder_apps) to do requests.

I don't have opinions on whether we need to support both template level AND per-coder_app. If there are use cases that you think are important (e.g. securing code-server app), then we'll need to do both... Maybe the template setting only applies to the ports dropdown and then each coder_app gets its unique config? Or we modify the ports dropdown to also have configurable CORS policies. That feels overkill which is why my first instinct was just one template-level setting

Thanks for the additional context, that helps.

@Emyrk @bpmct could we side-step this whole problem and insist that customers create a coder_app if they need to control CORS?

If not, I will add this add the port-share level. My only hesitation here is the UI will need to be updated, and honestly the UX of this component feels a bit awkward right now.

Users just have to know to click the lock icon to access the port-share, even though there's no UI indication that it's a button.

We'll have to make the whole panel a bit wider to accommodate the CORS behavior, and/or use some icons to indicate the behavior.
@chrifro your opinion here would be much appreciated.

Users just have to know to click the lock icon to access the port-share, even though there's no UI indication that it's a button.

Uh yes, that's not intuitive at all

We can definitely give the whole port menu a UI/UX polish when looking into this. Let me know once you have agreed on where the CORS settings should live and I can work on some designs.

@Emyrk @bpmct could we side-step this whole problem and insist that customers create a coder_app if they need to control CORS?

Nope we can't. Template admins and developers are totally different personas. Template admins in most cases will not understand what ports developers will be using since thousands of developers across different teams will be writing different apps.

@bpmct an argument for just the templates (to play devils advocate) is CORS is a security measure. And template admins should be able to control the security surface for the given template. 🤷‍♂

Saying that, I think the behavior should live in both. Unfortunate the UX will have to fit even more stuff.

A template-level setting is my preference. That way, it is up to the template admin:

@Emyrk @bpmct could we side-step this whole problem and insist that customers create a coder_app if they need to control CORS?

Nope we can't. Template admins and developers are totally different personas. Template admins in most cases will not understand what ports developers will be using since thousands of developers across different teams will be writing different apps.

Got it; I thought that CORS behavior changes would only be for well-known apps but I guess it could be for anything.

@bpmct an argument for just the templates (to play devils advocate) is CORS is a security measure. And template admins should be able to control the security surface for the given template. 🤷‍♂

Saying that, I think the behavior should live in both. Unfortunate the UX will have to fit even more stuff.

Can we start in the template (which is the simpler option), and expand to port-shares later if we get enough interest?

I suppose, I just can't imagine a scenario where a coder_app from one workspace needs to CORS to a coder_app on another users workspace.

I figured this was for user<>user collaboration on their projects. Such as a frontend developer using a backend's developer's port. I doubt the template admin will know/hardcode such ports as coder_apps. Heck, we don't and our template is for a single repo.

Just reviewed the 2 open tickets we have for this and they both refer to shared ports.

Edit: One does, not sure if the other does.

Ok from the chat:

• Doing this via shared ports is important as that is where the vast majority of applications will be running/shared. 80%+. coder_app is a partial solution
• We learned that other CDE products "pass through" CORS across the board and leave it up to the application
  • Coder did some special magic to make it so that local ports "behave like localhost": CORS is not permitted between multiple subdomain workspace apps  #5706 but this broke user<>user CORS entirely as per our docs
• Because of that, we are going to introduce a template-level setting to allow template admins to "remove the magic"
  .
• At the same time, we'll likely introduce app: add cors_behavior attribute terraform-provider-coder#309 so that if "passthrough" is set, somebody could still enable the magic for a specific application or two.

Moving this into the next sprint instead of this one.

I've pushed up my changes to change coder_app behavior: #15669
As discussed, we'll block the merging of this PR until we have the functionality in place for port shares.

Removing this from the sprint, we'll be able to pick it up in the new year at some point.

Closing this issue.

This issue has remained open and assigned for an extended period, but higher-priority tasks have taken precedence. As discussed in our recent Weekly call, we lack the bandwidth to conduct the rigorous testing required for the changes proposed in here.

Looking ahead, if priorities shift or the need arises to revisit this logic, it would be ideal to address it comprehensively -implementing E2E tests and releasing the improvements. For now, I’m closing this issue as unresolved.