In most cases, the header is passed as expected. Though there is one case where it does not happen. When the user hit the kibana URL in his browser, the very first call made by Kibana to Elasticearch is the following:
GET http://localhost:9200/.kibana/config/5.0.1
This call does not pass any header. I understand it is just for loading configuration from the kibana index. However, since it is related to the original user query, my plugin requires the user's headers to be present.
My question: How can I get these headers passed even by this API? If this is really not supported how could I change the code to have this happen?
I looked a little bit and have the impression it would be somewhere under src/ui/public/index_patterns. But honestly, i could not wrap my head around what is going on.
Looks like the spot in the code where this Kibana gets that config is called is src/ui/settings/index.js, in the getUserProvided function.
Some background information: elasticsearch.requestHeadersWhitelist is only for passing headers that come from the browser client to Elasticsearch. Sometimes the Kibana server also queries Elasticsearch, such as when it makes health checks on ES and, as is the case for getUserProvided, gets some settings in the .kibana index that are useful for page rendering and API responses that go back to the browser. Those calls are made with server.plugins.elasticsearch.client. That connection automatically provides the authentication credentials you put in kibana.yml as elasticsearch.username/password. Since the query doesn't originate from the browser, it doesn't include any headers that a browser would supply.
If you know what the full header data should be before you start the Kibana server, you can use elasticsearch.customHeaders in kibana.yml to have server.plugins.elasticsearch.client provide those headers in its requests.
Thanks for answering. The customer is wrapping kibana UI inside their own tool. So, when the user launches their tool, it calls kibana which is embedded in a sort of dashboard. This client tool then inject some headers at the browser level. The browser then sends them to Kibana, which we thought would forward them to ES.
I saw such calls as health and nodes that are not triggered by the client. I agree that those would not forward any header as in fact there is no user context. The one we are struggling with is "GET /.kibana/config/5.0.1", which is in fact called as a result of the user calling /app/kibana.
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.