Support cors_origins Wildcard domain

[f1amy]

Our application is multi-tenant, we're handling users from a dynamic number of subdomains.

We would like to setup authorization for Mercure subscribers, but it seems that it not possible with current configuration.

We've tried: cors_origins https://*.example.com, but Access-Control-Allow-Origin header is not appearing in responses from Mercure.

What can we do to fix this issue?

[f1amy]

It looks like using GET parameter authorization will work if we can't currently setup dynamic CORS origins

[TheJulienM]

I'd love to see this feature implemented! I have quite a few subdomains on several sites and it's getting to be a long list ^^

[Thomas-Philippot]

we have the same issue, hope this gets implemented !

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[f1amy]

Would be good to have

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[f1amy]

Needed

[mxmp210]

whatwg spec defines what values this header can have, have a look at Access-Control-Allow-Origin - which says

Indicates whether the response can be shared, via returning the literal value of the [Origin](https://fetch.spec.whatwg.org/#http-origin) request header (which can be null) or * in a response.

Unless spec itself allows it, there's no way browsers and apps will ever consider the sub wildcard notation. Allowing wildcards are a security risk in many cases, instead your infrastructure should be able to dynamically check and append header via proper proxy. Sub wildcards are simply not in the spec, so there will be more issues with browsers even if mercure allows it.

Edit : Duplicate of #768, it seems both issues can be closed, unless there's spec change.

[teohhanhui]

@mxmp210 This has nothing to do with the spec. Wildcard is just used for matching on the server side, and if the subdomain matches, return Access-Control-Allow-Origin with the correct origin value (no wildcard involved).

[mxmp210]

@mxmp210 This has nothing to do with the spec. Wildcard is just used for matching on the server side, and if the subdomain matches, return Access-Control-Allow-Origin with the correct origin value (no wildcard involved).

Spec is there for a reason. Allowing wild cards is a security risk, some orgs may not control subdomains directly. Thus spec does not allow it. Complying to spec is ideal and protects applications from misc users. Everyone can ignore it and have their own set of standards, but then there is no point in having standards that is well thought and enforceable to prevent these catastrophe. Also wildcards are not allowed browser side when credentials are present, server must return the specific path.

I get the point of having more flexibility server side, server can be made regex aware to allow and validate pattern based on white list and return proper path matching the spec. It should also honor these protection mechanisms while serving a request, that would be ideal. IMO this should be well discussed before implementing so the edge cases can be avoided, this is why it was pointed out in discussion.

[Loocos]

Maybe could we delegate that to Caddy? The CORS handler we use (Gorilla) is deprecated so removing it is also a good opportunity to remove fix this issue.

Originally posted by @dunglas in #768

Any workaround anyone could suggest according to his comment?
I tried few stuff but havn't been successful.