Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to whitelist client headers to be sent to elasticsearch #6132

Closed
epixa opened this issue Feb 5, 2016 · 2 comments
Closed

Ability to whitelist client headers to be sent to elasticsearch #6132

epixa opened this issue Feb 5, 2016 · 2 comments

Comments

@epixa
Copy link
Contributor

epixa commented Feb 5, 2016

With our legacy direct proxies to elasticsearch, we pass all headers from the client through to elasticsearch, which means people can pass custom headers to elasticsearch. This allows for, among other scenarios, elasticsearch/shield to be configured with custom realm support, and Kibana to pass along the necessary headers from the client.

However, we're moving to more explicit API routes on Kibana and in plugins, where developers will generally query elasticsearch using call_with_request rather than doing a direct proxy. This mechanism for querying elasticsearch currently only sends the Authorization header from the client, so it isn't possible to rely on any custom headers defined on the client.

It should be possible to configure specific headers that call_with_request will send along when they are provided by the client. This should be a whitelist behavior rather than a blacklist, and the only header that should be sent by default is Authorization.

It might also be worthwhile to apply the same whitelist to our direct proxies for 5.0 to remain consistent.

@epixa epixa added the discuss label Feb 5, 2016
@epixa
Copy link
Contributor Author

epixa commented Feb 5, 2016

/cc @lukasolson

@epixa
Copy link
Contributor Author

epixa commented Sep 20, 2016

This was addressed for #6221

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant