NOTICE: Elasticsearch Service changes to handling of CORS requests, on September 22, 2019


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: ''
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
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,
Access-Control-Allow-Methods: DELETE, GET, HEAD, OPTIONS, POST, PUT,
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

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?!

We ended up resolving this by deploying a brand new instance from a snapshot of the old one. The http.cors configuration worked on that instance as expected. We could then decommission the old instance.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.