search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.69k stars 8.24k forks source link

User Session ID Service #133109

Open afharo opened 2 years ago

afharo commented 2 years ago

Describe the feature:

We may need a new service in Kibana that tracks the session of a user in the UI.

To be clear, it's not the authenticated session, but a sort of tracking ID to provide some correlation for the navigation of the user through the UI.

Describe a specific use case for the feature:

There are some use cases in Kibana where we'd like to track the session ID of a user navigating through the Kibana UI. The most obvious one is traceability and correlation of the requests when troubleshooting.

This service may also be used as a replacement for the current getSessionId used in EBT.

Additionally, some features may use it as a seed in the random sampler aggregation.

Potential solutions:

  1. Extend the current getSessionId, moving it to its own service and setting it for any potential improvements in the future (i.e.: if there is no user activity for 10 minutes, clear the session).
  2. Use APM's session ID (when available): https://github.com/elastic/apm-agent-rum-js/issues/634

In either case, we may want to use executionContext's capabilities to forward this information to the server in the HTTP requests.

elasticmachine commented 2 years ago

Pinging @elastic/kibana-core (Team:Core)

pgayvallet commented 4 months ago

We may need a new service in Kibana that tracks the session of a user in the UI

@afharo do we have a better vision about this today?

afharo commented 4 months ago

Maybe @elastic/kibana-security has something that can help 😇

azasypkin commented 4 months ago

Maybe @elastic/kibana-security has something that can help 😇

We don't really have anything in security apart from the "authenticated session ID" at the moment. Additionally, the authenticated session isn't available in certain scenarios (proxy-authenticated and anonymous users) and is only recorded and can be tied to a particular user in the audit logs when available. So, it's likely not super useful for the use case described in this issue. That being said, if you end up having some synthetic "active user session" ID, it would probably make sense to record it in the audit logs as well.

By the way, you mentioned that you might want to clear this session once the user becomes idle. Is there any reason for that, instead of tying it to the authenticated user session?

afharo commented 4 months ago

By the way, you mentioned that you might want to clear this session once the user becomes idle. Is there any reason for that, instead of tying it to the authenticated user session?

I guess it depends on the definition of a user session ID: to me if someone leaves for lunch and comes back, it might be considered a new tracking session. Or maybe it's the daily usage in the office? 🤷

azasypkin commented 4 months ago

I guess it depends on the definition of a user session ID: to me if someone leaves for lunch and comes back, it might be considered a new tracking session. Or maybe it's the daily usage in the office? 🤷

I see, thanks. Then it sounds like we should first define what "tracking session" means exactly before we can determine which existing capabilities we can leverage, if any.

afharo commented 4 months ago

we should first define what "tracking session" means exactly

That's a great point! cc @shahinakmal, @elasticelvin, can you help us define what a tracking session would mean according to your expertise? Does it reset the moment a user becomes idle for N minutes? Is it linked to the login session (which can persist for days)? Anything else?

shahinakmal commented 4 months ago

From a historic perspective of other tooling, when treating sessions on tools that aggregate click-stream data for browsers, aa session is usually a window of 30 minutes of activity between to sessions of 30 minutes or greater of inactivity.

so it would reset after 30 minutes or more of inactivity.

I do not believe it would be good to have a session that persists for days at a time, at least when i think about a session, it's a user sitting and doing a specific activity for a set duration until they either achieve that outcome, or come back in a separate window.

A separate idea could be to add a session retroactively.Since we post this data to BQ we have unique user, actions and timestamps for each click or page view action. calculating a separate aggregate retroactive session table then using that as part of a query when referencing the elastic-edm-prod.parpt.rpttelemetry_prodebt_click_events or elastic-edm-prod.parpt.rpt__telemetry_prod__ebt_page_view tables is viable. However, it would only exist in BQ and may not solve for traceability and correlation of the requests when troubleshooting if you're using the kibana ui.

elasticelvin commented 4 months ago

I agree with everything Shahin said. 30 minutes is a pretty standard default. No activity after 30 minutes, take the last event as end of session timestamp. Sessions cannot continue/persist over days. You should automatically start a new session.