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 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?
I think this PR changed the behavior:
Just to confirm a suspicion, would you mind posting the error?
Frontends reported in a incident ticket
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 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).