Session idle timeout is triggered when session has been extended

[jportner]

Kibana version: 7.5

Elasticsearch version: 7.5

Server OS version: macOS Mojave 10.14.6

Browser version: Google Chrome 77.0.3865.120

Browser OS version: macOS Mojave 10.14.6

Original install method (e.g. download page, yum, from source, etc.): from source

Describe the bug: When a user makes certain API calls, the user's session gets extended due to user activity (e.g., "sliding session" expiration), but the session idle timeout notification does not get rescheduled. The notification displays anyway, and the logout event gets triggered, and the user is redirected to the login page.

Steps to reproduce:

1. Start a new ES cluster
2. In Kibana, set "xpack.security.sessionTimeout" to a low value (like 90000 ms)
3. Start Kibana
4. Log into Kibana and navigate to the Logs app
5. Click to view details on any log event
6. In your browser's developer tools, view the API call to "/foo/api/infra/graphql" and observe a new session cookie being set in the HTTP response header
7. Continue clicking view details on log events
8. After 30 seconds, the session idle timeout notification will be displayed
9. The session idle timeout notification will not be dismissed, even though the session is being extended with each API call
10. After a total of 90 seconds, the logout event will be triggered, the session will be destroyed, and the user will be redirected to the login page

Expected behavior: The session notification should be rescheduled when the session is extended. The behavior on other pages (such as Dashboard) is consistent with this expectation. The discrepancy seems to be that behavior is different when API calls are made to "/foo/elasticsearch/*" routes, which successfully reschedule the notification.

Screenshots (if relevant): N/A

Errors in browser console (if relevant): N/A

Provide logs and/or server output (if relevant): N/A

Any additional context: Every time an API call is made to the Kibana backend: 1. the browser's session cookie is authenticated, 2. the session "expires" value is updated, and 3. the old session cookie is overwritten with a new one. However, the session timeout notification isn't currently based on when the user's session actually expires. When the page loads, the session timeout notification is scheduled based on the server-side config value for "xpack.security.sessionTimeout".

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[legrego]

Similar to the reasoning here, it's possible that the server calls you observed aren't made using angular's $http service. If that's the case, then those calls will not influence the client-side session timer. This clearly isn't ideal, but may also be resolved or mitigated (untested) by #39477

[jportner]

Ah, okay.
I tested it with the #39477 changes and unfortunately that did not resolve the problem.

[kobelb]

It looks like the usage of apollo-client isn't integrated with the NP http service or kfetch, which is why the session timeout isn't being extended and the user is being logged out early...

[kobelb]

@elastic/kibana-platform how do you all feel about libraries besides the NP http service and kfetch being used for XHRs? Should we be trying to standardize on a library, or potentially integrate apollo-client with the NP http interceptors?