Originally I also overwrote CORS-related headers from the application (if it set any) but I ended up removing that because:

a) Currently users can already set their own headers (aside from OPTIONS requests) so this would be adding a new restriction I am not yet sure we want.
b) Not sure if allowing that has any security downsides. Nothing I can think of, at least. Nothing that uniquely affects cross-origin requests I should say.

Because we issue auth cookies based on each subdomain, I think we are going to get 403 forbidden on these CORs requests unless the user authenticated to the other domain first.

But we can handle that later, just going to crop up quick 😢

Because we issue auth cookies based on each subdomain, I think we are going to get 403 forbidden on these CORs requests unless the user authenticated to the other domain first.

Ahh good point, tested to confirm this is indeed a problem, the requests get redirected to auth.

But we can handle that later, just going to crop up quick

Yeah I will merge this in for now, I have no idea how we are going to solve it though. Maybe we can at least return an error on cross-origin requests that says "you have to go authenticate first". Or if we can somehow authenticate without the redirection.