# Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin'
**URL:** https://discuss.elastic.co/t/response-to-preflight-request-doesnt-pass-access-control-check-no-access-control-allow-origin/82571
**Category:** Kibana
**Created:** [April 17, 2017, 11:35am UTC](https://discuss.elastic.co/t/response-to-preflight-request-doesnt-pass-access-control-check-no-access-control-allow-origin/82571 "2017-04-17T11:35:43Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@jhn134910](https://discuss.elastic.co/u/jhn134910)
#### Post date: [April 17, 2017, 11:35am UTC](https://discuss.elastic.co/t/response-to-preflight-request-doesnt-pass-access-control-check-no-access-control-allow-origin/82571/1 "2017-04-17T11:35:43Z")
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](https://tangotelecom.com:5601/app/kibana#/dashboard/irldf_System_Dashboard?%E2%80%A6now-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](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/](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:
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](http://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](http://tangotelecom.com:5601)","connection":"keep-alive","pragma":"no-cache","cache-control":"no-cache","access-control-request-method":"GET","origin":"[https://tangotelecom.com](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](https://tangotelecom.com/rteDetails.html%22,%22accept-encoding%22:%22gzip), 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](https://tangotelecom.com/rteDetails.html%22%7D,%22res%22:%7B%22statusCode%22:404,%22responseTime%22:26,%22contentLength%22:9%7D,%22message%22:%22OPTIONS) /app/kibana 404 26ms - 9.0B"}
Any advise or guidance on how to trouble-shoot this further? Any help would be much appreciated. Thanks.
---
### Author:  [@shaunak](https://discuss.elastic.co/u/shaunak)
#### Post date: [April 17, 2017, 6:16pm UTC](https://discuss.elastic.co/t/response-to-preflight-request-doesnt-pass-access-control-check-no-access-control-allow-origin/82571/2 "2017-04-17T18:16:40Z")
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
---
### Author:  [@jhn134910](https://discuss.elastic.co/u/jhn134910)
#### Post date: [April 18, 2017, 8:28am UTC](https://discuss.elastic.co/t/response-to-preflight-request-doesnt-pass-access-control-check-no-access-control-allow-origin/82571/3 "2017-04-18T08:28:43Z")
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.
---
### Author:  [@jhn134910](https://discuss.elastic.co/u/jhn134910)
#### Post date: [April 18, 2017, 8:37am UTC](https://discuss.elastic.co/t/response-to-preflight-request-doesnt-pass-access-control-check-no-access-control-allow-origin/82571/4 "2017-04-18T08:37:06Z")
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](https://tangotelecom.com)" -H "Host: [tangotelecom.com:5601](http://tangotelecom.com:5601)" -H "x-proxy-user: irldf" -i localhost:9200
HTTP/1.1 200 OK
access-control-allow-origin: [https://tangotelecom.com](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](https://tangotelecom.com)" -H "Host: [tangotelecom.com:5601](http://tangotelecom.com:5601)" -H "x-proxy-user: irldf" -H "Authorization: Basic YWRtaW46zNDU=" -i [https://tangotelecom.com:5601/login](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: "/.\*/"'.
---
### Author:  [@jhn134910](https://discuss.elastic.co/u/jhn134910)
#### Post date: [April 18, 2017, 9:10am UTC](https://discuss.elastic.co/t/response-to-preflight-request-doesnt-pass-access-control-check-no-access-control-allow-origin/82571/5 "2017-04-18T09:10:02Z")
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: "/.\*/".
---
### Author:  [@jhn134910](https://discuss.elastic.co/u/jhn134910)
#### Post date: [April 18, 2017, 4:18pm UTC](https://discuss.elastic.co/t/response-to-preflight-request-doesnt-pass-access-control-check-no-access-control-allow-origin/82571/6 "2017-04-18T16:18:11Z")
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 .....
---
### Author:  [@jhn134910](https://discuss.elastic.co/u/jhn134910)
#### Post date: [April 20, 2017, 7:14am UTC](https://discuss.elastic.co/t/response-to-preflight-request-doesnt-pass-access-control-check-no-access-control-allow-origin/82571/7 "2017-04-20T07:14:33Z")
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
> [@Can someone share nginx config for reverse proxying Kibana4.4/4,5](https://discuss.elastic.co/t/can-someone-share-nginx-config-for-reverse-proxying-kibana4-4-4-5/46326/8):
>
> here:
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [May 18, 2017, 7:23am UTC](https://discuss.elastic.co/t/response-to-preflight-request-doesnt-pass-access-control-check-no-access-control-allow-origin/82571/8 "2017-05-18T07:23:18Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.