[QUESTION] how does prompt_for_basic_auth work?

1

hi,

Since I was trying the ROR Pro trial, I noticed that documentation says prompt_for_basic_auth should be set to false. I see and understand its need on the Kibana side. But when I removed ROR Pro for Kibana, I had left out this entry by mistake on the config on the ES side of ROR. So when I tried to access the elasticsearch URL from the browser, I was directly getting forbidden by ROR message.

So my question is that when this option “prompt_for_basic_auth” is set to false, will the other elasticsearch REST API calls fail directly or can they still be invoked successfully as long as we are passing the basic authentication information on the REST API call.

We are using .Net NEST client and doing something similar as shown below as part of the connection. So will this ensure that even though prompt is set to false, the calls can still happen successfully as long as basic auth information is passed along OR will the REST calls also face similar problem (forbidden by ROR message)?

var settings = new ConnectionSettings(new Uri(mEsQuerySource.Url));
settings.BasicAuthentication("userid", "password");
mClient = new ElasticClient(settings);

Thanks!

2

“prompt_for_basic_auth” is used to decide if we need to return 403 or 401 error codes when credentials are absent or invalid. Nothing more, nothing less :slight_smile:

3

Got it. For our service based calls, since we are passing basic auth, I think we should be fine.

But I would kindly suggest that probably you should consider the option of having this parameter split out for ES and Kibana based calls, if possible. I understand that for Kibana Pro, there is a separate nice login page provided. But if someone tries to access the ES REST end points directly from browser, then not getting this login prompt will essentially limits its usage. One simple use case could be someone wanting to quickly check the cluster status or node status. There could be other use cases as well.

4

Just use the API key rule for this kind of things. No?

5

Ok. So when we use api_key rule, will the request look something like this? Is this the correct usage, when directly giving the URL in browser?

https:/1234567890123456789@mysite.com/_cluster/health

6

No that would be a basic HTTP auth username without a password.

See the api_keys rule in the docs. ROR will expect an AWS style X-Api-Key request header.

7

Not exactly browser friendly, one might argue. Probably the basic auth embedded in the url would be the best bet.

https://username:password@yourEs:9200/_search

8

That is not going to be useful as we will be providing these kind links to infra teams that will internally set them on monitoring tools like Tivoli which would then hit the cluster every n minutes to do health check. I think in worst case, we will have to setup Id that gives very limited access to allow them to run the cluster health apis. That is why I was suggesting that you should probably consider splitting that feature so that people can control the behavior in ES and in Kibana separately.