Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin'

Elastic Stack Kibana
1

Hello there,
I'm getting a failure for an Options pre-flight request:

XMLHttpRequest cannot load https://tangotelecom.com:5601/app/kibana#/dashboard/irldf_System_Dashboard?…now-1d,mode:absolute,to:now))&_a=(filters:!(),title:irldf_System_Dashboard).
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://tangotelecom.com' is therefore not allowed access. The response had HTTP status code 404

My CORS configuration in elasticsearch.yml is:
http.cors.enabled: true
http.cors.allow-origin: "/.*/"
http.cors.allow-credentials: true
http.cors.allow-headers: "X-Requested-With,Content-Type,Content-Length,Authorization,x-proxy-user"

I'm logging into https://tangotelecom.com/. Then I navigate to page that is making an ajax request to kibana:

var xhr = new XMLHttpRequest();
xhr.open('GET', tempUrl);
xhr.onreadystatechange = iFrameHandler;
xhr.responseType = 'blob';
xhr.setRequestHeader('x-proxy-user', 'irldf');
xhr.setRequestHeader('Authorization', 'Basic ' + btoa('admin'+':'+'tmp12345'));
xhr.withCredentials = true;
xhr.send();

The reason I'm setting the 'x-proxy-user' and 'Authorization' headers is that they are going to be used by a X-Pack custom realm plugin later for authentication purposes. From chrome network tab my Option request and response headers is as follows:

options_headers.png800×441 30.5 KB

I'm using version 5.1.2 of elastic-search, kibana and x-pack. My kibana configuration (kibana.yml) is bound to
server.port: 5601
server.host: "tangotelecom.com"

From the kibana logs a request looks as follows:
{"type":"response","@timestamp":"2017-04-17T11:18:09Z","tags":,"pid":117443,"method":"options","statusCode":404,"req":{"url":"/app/kibana","method":"options","headers":{"host":"tangotelecom.com:5601","connection":"keep-alive","pragma":"no-cache","cache-control":"no-cache","access-control-request-method":"GET","origin":"https://tangotelecom.com","user-agent":"Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36","access-control-request-headers":"authorization, x-proxy-user","accept":"/","referer":"https://tangotelecom.com/rteDetails.html","accept-encoding":"gzip, deflate, sdch, br","accept-language":"en-US,en;q=0.8,en-GB;q=0.6"},"remoteAddress":"192.168.25.188","userAgent":"192.168.25.188","referer":"https://tangotelecom.com/rteDetails.html"},"res":{"statusCode":404,"responseTime":26,"contentLength":9},"message":"OPTIONS /app/kibana 404 26ms - 9.0B"}

Any advise or guidance on how to trouble-shoot this further? Any help would be much appreciated. Thanks.

1 Like
2

Hi John,

It seems a bit odd that you are programmatically (that is, using XMLHttpRequest) trying to request a user interface (as opposed to an API) URL. May I ask why you are doing it this way? Depending on your answer, there might be a better way to accomplish what you are trying to accomplish here.

Thanks,

Shaunak

3

Hello Shaunak,
Thanks for your response. I guess it's a bit odd alright. Here's what I'm trying to achieve:

I'm developing a custom realm plugin for x-pack that I'm attempting to test as proof-of-concept. This custom realm takes information from HTTP headers. It gets the tenant from the header x-proxy-user, and it gets user name and password from an Authorization header. To avoid sending password in plain x-pack is also providing a HTTPS termination. X-Pack is installed in both elastic-search and Kibana. Previously, I had no x-pack or security and I just put kibana dashboard URL into src attribute of iFrame, but now I need to add headers for authentication purposes. I was looking at approaches similar to

to pass said headers. Another approach would be to add a proxy like nginx between my browser and kibana and get it to add the headers. However, as Kibana is providing a HTTPS termination, I'd have the hassle of terminating HTTPS at nginx, then adding the headers and then repackaging in HTTPS envelope again. I was trying other options before I went down that route.

4

Leaving ajax request aside for a second. Some further items that may be of interest here:

[tango@iel-dev-tfsr-vm1 09:33:41 john]$ !1206
curl -H "User-Agent: Mozilla" -H "Origin: https://tangotelecom.com" -H "Host: tangotelecom.com:5601" -H "x-proxy-user: irldf" -i localhost:9200
HTTP/1.1 200 OK
access-control-allow-origin: https://tangotelecom.com
access-control-allow-credentials: true
content-type: application/json; charset=UTF-8
content-length: 327

{
"name" : "vCUgnmd",
"cluster_name" : "tango-cluster",
"cluster_uuid" : "Z9pwWEndQ_my2_AYYzHArA",
"version" : {
"number" : "5.1.2",
"build_hash" : "c8c4c16",
"build_date" : "2017-01-11T20:18:39.146Z",
"build_snapshot" : false,
"lucene_version" : "6.3.0"
},
"tagline" : "You Know, for Search"
}

With the cors configuration in elasticsearch.yml already mentioned, I would have expected the response here to include the Access-Control-Allow-Headers response header?

Also, when attempting to communicate with Kibana directly:
[tango@iel-dev-tfsr-vm1 09:33:58 john]$ curl -v --cacert /tango/config/ssl/tangotelecom.com.cert.pem -H "User-Agent: Mozilla" -H "Origin: https://tangotelecom.com" -H "Host: tangotelecom.com:5601" -H "x-proxy-user: irldf" -H "Authorization: Basic YWRtaW46zNDU=" -i https://tangotelecom.com:5601/login

I get the following response headers, but not CORS related response headers:
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< kbn-name: kibana
kbn-name: kibana
< kbn-version: 5.1.2
kbn-version: 5.1.2
< kbn-xpack-sig: 38858c5347d51980cc750536938b88ed
kbn-xpack-sig: 38858c5347d51980cc750536938b88ed
< cache-control: no-cache
cache-control: no-cache
< content-type: text/html; charset=utf-8
content-type: text/html; charset=utf-8
< content-length: 43453
content-length: 43453
< accept-ranges: bytes
accept-ranges: bytes
< Date: Tue, 18 Apr 2017 08:37:00 GMT
Date: Tue, 18 Apr 2017 08:37:00 GMT
< Connection: keep-alive
Connection: keep-alive

I'll try a few things here. Maybe binding elastic-search to localhost is a problem, and I'll change the configuration to accept all headers, 'http.cors.allow-headers: "/.*/"'.

5

Just FYI. When I bind elastic-search to same host as kibana I get the same result, and I get the same result if I set http.cors.allow-headers: "/.*/".

6

I also tried setting the following:

elasticsearch.requestHeadersWhitelist: [ authorization, origin, host, x-proxy-user ]

in kibana.yml to allow the options requests headers to be passed down to elasticsearch in order to get the Access-Control-Allow-Origin in the response, but I'm really just guessing and trying things .....

7

Looks like even though elastic-search supports CORS, kibana does not and there doesn't appear to be any handling for Options requests.

The only solution I came up with for my requirements was to introduce a web-proxy in front of kibana, so that kibana and my other services were running in the same domain. For that I used nginx and the steps documented at

1 Like
8

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