Hi,
We've been trying for a few weeks to address this notice that Elastic send out.
All Elasticsearch Service clusters will default to http.cors settings after September 22 2019.
Elasticsearch Service clusters provisioned on Elastic Cloud prior to January 25th, 2019 have a CORS policy set at the proxy layer. This is now deprecated, and we will be moving to a model that requires customers to configure their own http module CORS policy to their needs. These settings are configurable as Elasticsearch user settings for a cloud deployment. This is applicable for all clusters.
If your use case depends on the ability to receive CORS requests and you have a cluster that was provisioned prior to January 25th you will need to manually apply http.cors settings to your cluster prior to the September 22 deadline, or you will potentially have an operational impact.
We have an Elastic 6.1.3 cluster (1 node) and no custom config at all. However I can see our app does get CORS responses from the server, so I assume this is the Proxy layer they are deprecating.
I went in an setup the http.cors config in exactly the same way we get from the proxy right now:
http.cors.enabled: true
http.cors.allow-origin: 'https://www.REDACTED.com'
http.cors.max-age: 60
http.cors.allow-methods: DELETE, GET, HEAD, OPTIONS, POST, PUT
http.cors.allow-credentials: true
http.cors.allow-headers: Authorization, Content-Type, Origin, Accept, X-Requested-With
(I set the max-age to 60 as a temp measure to avoid any client caching issues).
I see this in the request:
Access-Control-Request-Headers: authorization
Access-Control-Request-Method: HEAD
Origin: https://www.REDACTED.com
Referer: https://www.REDACTED.com/app-path
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
And in the response:
Access-Control-Allow-Credentials: true, true
Access-Control-Allow-Headers: Authorization, Content-Type, Origin, Accept,
X-Requested-With, authorization,
Authorization,Origin,Accept,X-Requested-With,Content-Type
Access-Control-Allow-Methods: DELETE, GET, HEAD, OPTIONS, POST, PUT,
HEAD,DELETE,POST,GET,OPTIONS,PUT
Access-Control-Allow-Origin: https://www.REDACTED.com,
https://www.REDACTED.com
Access-Control-Max-Age: 1728000, 60
Connection: keep-alive
Content-Length: 0
Date: "Fri, 13 Sep 2019 08:51:34 GMT"
Vary: origin
X-Cloud-Request-Id: k6RP-g6mSUu7uj8A-UUZsg
X-Found-Handling-Cluster: 075b32754f52d1eb0f2ec2bc52d7xxxx
X-Found-Handling-Instance: instance-0000000009
X-Found-Handling-Server: 172.27.78.xxx
Why is it outputting the header values twice?!
Has anyone else had any issues sorting out this CORS policy change that's being enforced?
For now, I've left the cluster with "http.cors.enabled: false" to get the app working again, however I can still see CORS headers from Elastic (which I assume is from the Proxy layer).
Can I disable the proxy layer?!