Kibana link is lost after authentication

When we click a kibana link to a dashboard, we occasionally lose the original link if the current session needs to re-authenticate, and we are left with the default screen after logging in. This is very problematic for some of our users we give the URLs to (via watcher actions). The users don't realize what's going on and don't know what screen to expect.

This only happens in our production environment (elasticsearch version 6.8.5). Our dev environment is 7.5.1 and it doesn't happen there. Is there anything we can do to stop this behavior in prod (we're not ready to upgrade it yet).

I wanted to add the following in case someone can add to it:

Hi @Matt_McGovern!

There's nothing super great you can do. The issue was fixed in 7.5 which is why your dev environment isn't running into any troubles.

Some less than ideal things you could try:

  1. Patching your 6.8.5 version of Kibana with the fix for this issue (PR #44513 fixed the issue)
  2. Extending your session timeout (this wouldn't solve the issue, only make it less frequent)

We just verified that this issue is not fixed in Dev (7.5). The problem is caused by the length of the URL. We have watchers that have links to pre-existing dashboards. We like to send query strings along with the dashboard that are unique to each watcher action, so the URL tends to get very large.

A smaller URL fixes all this. We're currently stuck discussing how to get a call to the URL shortening API somehow. The watcher cannot call this API, and the stored script cannot call it (unless this has changed?). All of our watchers call a stored script and it would be great if we could somehow reduce the size of the URL in there.

Any thoughts?

:thinking: To call the URL shortener, no...

But, does adjusting the maxRedirectURLSize fix your issue? Can try setting it to 0 and then adjust upwards if it fixes the issue.

This may be our solution, as we don't have that setting in our yml file, so we are at the default which is 2KB (max is 4KB).

Do you happen to know if there's an API call to change that setting, instead of having to do a restart? I'm searching online but can't find it. I see in DevTools that isn't available for xpack or _xpack.

Also, if it has to go into the yml file, is it kibana.yml or elasticsearch.yml?

This'll go in kibana.yml

Doesn't seem like there's an API for it unfortunately — feel free to open an enhancement request on Github for that though!

Last question on you know the correct format for putting this in the kibana.yml file? We're getting the following error:

FATAL Error: []: expected value of type [array] but got [Object]

Our original line in our kibana.yml file is: [saml, basic]

We tried putting the following but got the error: [
order: 0
realm: saml1
maxRedirectURLSize: 4kb,
order: 1

Also it just occurred to me that we have saml settings in our elasticsearch.yml file with in there already. Should that be what we are referring to?

Lastly, let me know if you think I should create a support ticket with ES for this. They always said I should try here first.

Hey @Matt_McGovern,

Do you happen to know if there's an API call to change that setting, instead of having to do a restart?

@myasonik is right, the only way to adjust these settings is via yml today. We've resisted offering APIs for adjusting sensitive settings such as these. Having physical write access to the yml file is an additional layer of security here.

do you know the correct format for putting this in the kibana.yml file? We're getting the following error:

Try the following format in your kibana.yml. Note that I used comcastsaml as the realm name here to match what I presume you have in your elasticsearch.yml based on your comment above:
      order: 0
      realm: comcastsaml
      maxRedirectURLSize: 4kb
      order: 1

(also note this syntax won't work for for your 6.8 installation).

Let me know if this syntax works for you, or if you have any other questions.

This format worked for us, in that we were able to bring up the node. It didn't fix our original problem when the dashboard URL is too large AND re-authentication happens. Thanks for your help, though. It's good to know of this.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.