Allow Access-Control-Allow-Origin header

[dshelters]

Initial checklist

• I understand this is a feature request and questions should be posted in the Community Forum
• 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