CORS using IIS with ARR and URL Rewrite as a reverse proxy

Question

I'm using IIS with ARR and URL Rewrite as a reverse proxy in order to support HTTPS connections to an ElasticSearch server. ES is configured correctly, as far as I can tell, and direct HTTP connections to ES do not result in an error.

When I connect via the proxy, however, I get this error in the browser:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://myserver:19201/myindex/_search . (Reason: missing token 'authorization' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel)

The relevant section from the elasticsearch.yml file is this:

http.cors.enabled: true
http.cors.allow-origin: "*"
http.cors.allow-headers: ["X-Requested-With","X-Auth-Token","Content-Type","Content-Length","Authorization","engine-name"]
http.cors.allow-credentials: true

Is there something special I need to do to enable these requests through the proxy, or is this a fool's errand, and I should look for another option?

Answer 1

You can write the headers by yourself in the web.config under as you can see in this answer.

But better use the official module: The IIS CORS module .

In your case, you need this config:

<cors enabled="true">
  <add origin="THE_URL_YOU_USE_IN_YOUR_BROWSER" allowCredentials="true">
    <allowHeaders allowAllRequestedHeaders="true">
      <add header="X-Requested-With" />
      <add header="X-Auth-Token" />
      <add header="Content-Type" />
      <add header="Content-Length" />
      <add header="Authorization" />
      <add header="engine-name" />
    </allowHeaders>
    <allowMethods>
        <add method="GET" />
        <add method="OPTIONS" />
        <add method="POST" />
        <add method="DELETE" />
        <add method="PUT" />
        <add method="HEAD" />
    </allowMethods>
  </add>
</cors>

Answer 2

So one way you should be able to get it to work is by setting CORS to allow all origins:

Access-Control-Allow-Origin: *

You can set this in IIS under HTTP Response Headers.

However, this defeats the purpose of using CORS in the first place, and is probably not recommended from a security perspective.