# CORS plugin breaking changes from 0.14.x to 1.0

**URL:** <https://discuss.konghq.com/t/cors-plugin-breaking-changes-from-0-14-x-to-1-0/2675>\
**Category:** General\
**Created:** [January 23, 2019, 4:36pm UTC](https://discuss.konghq.com/t/cors-plugin-breaking-changes-from-0-14-x-to-1-0/2675 "2019-01-23T16:36:48Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![jeremyjpj0916](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/jeremyjpj0916/32/1388_2.png) [@jeremyjpj0916](https://discuss.konghq.com/u/jeremyjpj0916)\
**Post date:** [January 23, 2019, 4:36pm UTC](https://discuss.konghq.com/t/cors-plugin-breaking-changes-from-0-14-x-to-1-0/2675/1 "2019-01-23T16:36:48Z")

</div>

Seems there was a breaking change to CORS, we caught it in our Stage environment.

We used to configure the origins field with (.)[company.com](http://company.com) to allow for a regex of subdomains on 0.14.x, in 1.0 this errors and isn’t supported. We ended up having to reconfigure the few proxies leveraging CORS plugin to \* that needed wildcarding but that is not very restrictive. Is there an alternative to the original regex we were using that works?

Relevant:

> <https://github.com/Kong/kong/blob/master/CHANGELOG.md#plugins-4>

I think this PR changed the behavior:

> <https://github.com/Kong/kong/pull/3872>

---

<div class="post-metadata">

**Author:** ![thibaultcha](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/thibaultcha/32/340_2.png) [@thibaultcha](https://discuss.konghq.com/u/thibaultcha)\
**Post date:** [January 24, 2019, 2:43am UTC](https://discuss.konghq.com/t/cors-plugin-breaking-changes-from-0-14-x-to-1-0/2675/2 "2019-01-24T02:43:39Z")

</div>

> [@jeremyjpj0916](#):
>
> in 1.0 this errors and isn’t supported

Just to confirm a suspicion, would you mind posting the error?

---

<div class="post-metadata">

**Author:** ![jeremyjpj0916](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/jeremyjpj0916/32/1388_2.png) [@jeremyjpj0916](https://discuss.konghq.com/u/jeremyjpj0916)\
**Post date:** [January 24, 2019, 4:26am UTC](https://discuss.konghq.com/t/cors-plugin-breaking-changes-from-0-14-x-to-1-0/2675/3 "2019-01-24T04:26:52Z")

</div>

Frontends reported in a incident ticket

```auto
We’re getting a CORS No 'Access-Control-Allow-Origin’ header is present issue 

```

After the upgrade.

When somehow on 0.14.1 with (.)[company.com](http://company.com) it was working for them. I have not studied into it too much @Ross_Sbriscia spent the whole day yesterday documenting CORS and how we intend to leverage it internally so hopefully he can go into more detail about the seen differences tomorrow here in 0.14.1(which luckily we run in prod and can still test next day or two vs 1.0.2(which we now run in dev/stage). Would it make sense for the CORS plugin to evaluate the origins with detected regex and return access-control-allow-origin values that match a wildcard if passed on the preflights?(not sure if this was a feature of 0.14.1 or not, I checked the 1.0.2 CORS code briefly and it looked very basic, basically if null do \* , if \* do \* and then full list of FQDNs is another option).