Kibana session timeout needs to better handle additional activity

[alexfrancoeur]

When using the xpack.security.sessionTimeout setting in Kibana to control user session timeout, there needs to be a better way to handle additional "normal" activity.

For example, if a user is making query edits in the Kibana Dev console and remains on that page for the duration of the session timeout, the typing and mouse movements in the Dev Console currently do not reset the timeout (the same is true for working solely on the Dashboards edit screen, and other areas). The user will be logged out at session timeout even though they were actively working on that single page the whole time.

[jportner]

Several of the issues linked here had root causes that were related, but not exactly the same.

We recently overhauled session timeouts with #49855 starting in Kibana 7.6 --
The client code no longer guesstimates the session expiration, it actually makes an API call to the server to check when the session will expire. In addition, the browser tabs communicate with each other when session info is updated, so they stay in sync.

However, for this particular problem of a "false positive" timeout -- staying on a single page and client-only activity does not trigger the sliding session window -- we don't have a solution yet. Currently, the only metric we have for user activity is when their browser makes a "non-system" (user-originated) API call. This is problematic in its own right, because some other pages make these types of API calls in the background, without any user intervention -- which results in a "false negative" timeout.

The good news is, the recent changes that expose session timeout info to the client and an API to get/extend it, we laid the groundwork to improve how we handle client-side activity to determine idleness.