Allow `Access-Control-Allow-Origin` header

[dshelters]

Initial checklist

• [X] I understand this is a feature request and questions should be posted in the Community Forum
• [X] I searched issues and couldn’t find anything (or linked relevant results below)

Problem

The docs state that the corsOrigins (and by extension, the COMPANION_CLIENT_ORIGINS env var for standalone) "is used for [the] CORS’ Access-Control-Allow-Origin header," but the Access-Control-Allow-Origin is never allowed by the companion server. This should be an allowed header on companion so that the client can set this header when making requests to companion.

Solution

First option is simply to update the docs so that they do not state that this variable / option will be used for this header, because it's not an allowed header at all in Companion. Better if they inform developers that the Access-Control-Allow-Origin header is not an allowed header which can be sent to companion.

Alternatives

Even better, IMO, would be to allow the client to verify the Access-Control-Allow-Origin header. If I'm understanding the Companion code correctly, it seems like it sends requests to itself for different tasks, and on those requests, it uses the headers from the original client request. I understand how this would cause a problem, because now the origin is different. But I think that can pretty easily be remedied.

When COMPANION_CLIENT_ORIGINS is set to a non-true string (or corsOrigins), we could:

• Include access-control-request-headers in allowedHeaders in when exporting the cors function
• When creating headers for internal requests based on the initial request, like in uploadMultipart, either delete or update any Access-Control-Allow-Origin or Access-Control-Request-Headers that specify the origin.
• Remove access-control-request-headers from the blacklist of client headers

[cppntn]

Any update or workaround on this? @mifi @dshelters

[mifi]

Hi! TBH I'm a bit confused by all these Access Control headers.

1. Not sure I understand exactly why this header needs to be sent. Do you get an error without it?
2. You're asking for the possibility to send Access-Control-Allow-Origin from the client to the server (which you're saying it currently rejects). However isn't Access-Control-Allow-Origin a response header, sent by the server to the client, not sent by the client to the server?
3. You're also talking about access-control-request-headers, but TBH I'm not sure about its relation to Access-Control-Allow-Origin

If the changes you'd like to see are not that large, maybe you could create a PR and maybe that'll better illustrate what you want?