Request: enable multiple origins in CORS plugin

[nsaliu]

Hi,
I've a question (or request... ;))

Is planned to enhance the CORS plugin to allow multiple origins?
At the moment I can add only one origin, or the "*" for allow all.

Thanks.

[nijikokun]

Not currently planned, doing so would require doing some matching on the origin of the request, as in the specification the origin-list is more strict in production allowing only a single domain or * / null.

A few common suggestions are to do a regex check against the origin as I also suggest above.

Adding this as a note for anyone who is interested in patching the CORS plugin to provide this functionality, as I am unsure whether such a possibility is possible from within the plugin itself.

Doing some digging you could emulate this common suggestion using ngx.var.http_origin which would be that variable to do so.

Thoughts?

[jmdacruz]

I think that being able to configure the Access-Control-Allow-Origin header based on the Origin header is the way to go (based on all of the recommendations that @nijikokun mentioned on the previous comment), regardless on how the comparison is carried out (direct comparison, regex, etc.). This is a critical feature if you consider that browsers do not allow a CORS header with a permissive value (*) when the request has any form of authentication using headers (e.g., the Authorization header, which is used for basic auth, OAuth, etc.)

[nicksamps]

@jmdacruz +1

We are having issues because we need to allow credentials from multiple domains :(

[prajjwol]

@thefosk would love to have this as a feature too. Any implementation suggestions to work around for now?

[hnq90]

👍
I need the allow credentials from all my sub-domains.

[subnetmarco]

I was thinking to add a new configuration property to the plugin, called something like config.origin_by_client. If set to true, it will return an Access-Control-Allow-Origin valued to whatever Origin value has been requested by the client.

Or config.origin_by_client=[regex].

Does this make sense?

[jmdacruz]

The plugin would definitely need some sort of whitelist of Origin values that are allowed, and this can be either a list of strings or a regex. You can go one step further and make it a hybrid list of either regex expressions or plain strings (this would be better than a complex regex trying to match multiple domains with subdomains, etc.).

I would do something like this:

• Keep the current origin parameter and add a new origins parameter. At least one of the two should be required
  • For backwards compatibility, you could allow both values to be provided, in which case you created a merged list of values from both origin and origins
• The new origins parameter would be an array. Each of the elements on that array can either be a plain string (matched with plain string matching against the incoming Origin header) or a regex
• The way you would distinguish whether the value is a plain string or a regex is using the classic perl format of /expression/
  • Since the values for the Origin header will never contain slashes (because they always represent domain names) this is a safe way to identify when the value is a regex

So, you would end up with a configuration such as:

curl -X POST http://kong:8001/apis/{api}/plugins \
    --data "name=cors" \
    --data "config.origin=mockbin.com" \
    --data "config.origins=subdomain.mockbin.com, /.*\.something\.mockbin\.com/" \  
    --data "config.methods=GET, POST" \
    --data "config.headers=Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Auth-Token" \
    --data "config.exposed_headers=X-Auth-Token" \
    --data "config.credentials=true" \
    --data "config.max_age=3600"

Where mockbin.com is a value provided by the current origin parameter, subdomain.mockbin.com is a string/literal value provided on the new origins array parameter, and /.*\.something\.mockbin\.com/ is a regex provided on the new origins array parameter.

What I like about this approach is that it can be used with a basic list of domains in scenarios where you can easily enumerate them, but you also have the power to use regex when needed. It also avoids the need of a boolean flag completely, and it remains backwards compatible with applications from a registration point of view.

Ultimately, you could consider avoiding the origins parameter completely and simply transforming the existing origin parameter into an array... but this might have other consequences from the data migration point of view on the plugin (not sure...). Alternatively, you can just implement the origins parameter and then at some point deprecate the origin parameter.

[vl4d]

We have been using our own custom plugin as specified in #1774 , where we just have a configured list of domains to allow, for a while now (about 8 months).

There is a concern where this list becomes massive.

Would love to see this supported so we don't have to update ours every time kong updates the cors plugin.

[jdeibe]

Agree, looking forward for support for multiple domains for CORS in the plugin.

[p0pr0ck5]

This was done in #2203!