But the POST fails on the preflight OPTIONS call when the header 'kbn-version' is present.
And if I remove the 'kbn-version' the OPTIONS call is successful but the subsequent POST fails because the 'kbn-version' header is not present.
This OPTION call is in error when 'Access-Control-Request-Headers' contains 'kbn-version'.
I did a search on web server used by Kibana (HAPI JS) and the cors option when the server is set up.
We can use a full json object for a better customization instead of true or false.
And with a complete configuration I was able to log my user automatically.
Is it possible to specify this configuration inside kibana.yml (server.cors allow only boolean) ?
It would be very usefull to parameter a specific origin domain and more.
You're hitting a slightly embarrassing point here. The server.cors setting accepts different values depending on whether Kibana runs in development or production mode. In dev mode it accepts a full hapi cors config object like the one you showed, but in production mode it only accepts a boolean.
Since I can not in good conscience recommend running Kibana in production, one solution I can think of (until this inconsistency is changed) would be to use a reverse proxy in front of Kibana to strip out the kbn-version entry from the Access-Control-Request-Headers list (assuming it still works fine on the POST). Another option would be to avoid the cors problem altogether by reverse-proxying Kibana on the same domain as the embedding website.
Sorry, I can't give you any specific roadmap dates. The server.cors setting is not documented at the moment since we don't want to expose internals. Running Kibana behind your own reverse proxy and managing headers there would be our recommended approach for now.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.