Error Messages handling In Kibana UI

Elasticsearch version: elasticsearch-oss-7.0.1

Kibana version (if relevant): kibana-oss-7.0.1

Describe the issue:
When an unauthenticated user logs in to view the indices, Kibana prompts the Message saying No Permission.
After that, the correct index selected, still the error message visible. We have to click explicitly ‘ok’ to cancel the error prompt.

Steps to reproduce:

  1. Deploy elk 7.0.1 chart with some users having limited permissions.
  2. Login with admin user and create some index patterns.
  3. Log in with unauthenticated user which have limited permissions and try to view the indices, Kibana prompt the Message saying No Permission.
  4. Now use the correct index for which user has permissions the error message is still there.

Expected behavior:
When we select the correct index the error message should disappear.

Screenshots (if relevant):

This happens because the user tries to read some index(es) that he has no permission to read. In some cases, Kibana uses a wildcard as an index name if no index name is given. Search Guard can be run in do not fail on forbidden mode. With this mode enabled Search Guard filters all indices from a query a user does not have access to. Thus not security exception is raised. You can enable it in the following way.

sg_config.yml

sg_config:
  dynamic:
    do_not_fail_on_forbidden: true

If there is a permission error, usually the corresponding Elasticsearch error is more useful. Could you please look at the Elasticsearch log, find the related error, and paste it here?

Hi @srgbnd
Thanks for the response.
I have tried do_not_fail_on_forbidden: true parameter under sg_cofig. Now when an unauthenticated user logs in to view the indices, Kibana prompts the Message saying “Internal Server Error”.
If we click on the index for which user have permission the prompt is still there. That prompt remains until we click explicitly on “ok” button. The prompt should be disappear if we select the correct index for which user have permssion.
The only different which I see in client logs are with do_not_fail_on_forbidden parameter there are no logs coming for “Internal Server Error”. Without that parameter, we can see “no permission” logs in client pod.
Our expectation is the prompt for no permission should disappear when we select the correct index .

Thanks,
Prashant

Hi. Today I tested this locally.
There is no Internal Server Error if a user has search permissions for the selected index pattern.

There is the error if the user doesn’t have the search permissions.

If the user clicks Ok to close the error callout and switches back to the index he has permissions for, there is no error. If the “correct” index pattern is preferred, the user navigate to other pages and goes back to the Discover page and there is no error.

Do you have the same behaviour? If yes, it is expected. This error is the Kibana error, we don’t control this error. It disappears after the timeout you see in the right (270s) or after the user clicks the Ok button.
Screenshot 2020-09-21 at 11.23.13

Thanks @srgbnd

Yes, we have the same behavior as above.

In the newest Kibana/SG versions. We have clear messages if the user has no permission to search indices behind an index pattern.

The user switches to the index pattern he has no permission to search.

The user clicks the “See the full error” button.

Hi @srgbnd
One doubt in newest Kibana/SG versions. After doing this “The user switches to the index pattern he has no permission to search” if user select the correct index(for which he has permission). That error prompt still be there ?

There is no error on the page if the user switches to the “correct” index pattern.

The error prompt should automatically disappear once we select the correct index,right ?

If there was an error, Kibana pops the related error toast. There is one toast per error. If the user has the error already and switches to the “correct” index pattern the toast doesn’t disappear immediately. It either disappears after a timeout or when the user closes it. There is no other error on the page.

ok @srgbnd
Thanks a lot.

Hi @srgbnd
On what parameter this “timeout” decided? Because in older kibana/SG version it shows for 300s and in newer version there is no timeout coming.

Currently, all toasts in the Kibana global toast list has the timeout (toastLifeTimeMs) set to Infinity. https://github.com/elastic/kibana/blob/7.9/src/core/public/notifications/toasts/global_toast_list.tsx#L72

It either disappears after a timeout …

So, I have to take this back. Practically the toast is there until the user closes it.

Previoulsy the value is set to 6000Ms. https://github.com/elastic/kibana/blob/7.1/src/core/public/notifications/toasts/global_toast_list.tsx

but the time comes up on error prompt is 300s. In that case both time should be same ?
So the parameter “toastLifeTimeMs” is for timeout or for some another purpose ?

The red message at the top of the page which is saying Internal Server Error in v7.0 is not in the EuiGlobalToastList. The toast list is a completely different UI component. It always looked this way https://elastic.github.io/eui/#/display/toast

Is there any way to configure error prompt timeout(which is by default 300s) in older version of kibana ?

Practically the toast is there until the user closes it:- I have validated it even there was no countdown time but after some the error prompt disappears itself.

You can configure Kibana only via kibana.yml. I don’t see any option to set the error timeout https://www.elastic.co/guide/en/kibana/7.x/settings.html