Session monitor
What it answers
Section titled “What it answers”An audit log answers “who did what”. The session monitor answers the other question: who is in right now. That is the view you need when an account looks suspicious, when old logins might still be open after a password change, or simply when you want to know whether anyone besides you is working in the system.
Find it in the admin panel under Sessions.
What the table shows
Section titled “What the table shows”| Column | Meaning |
|---|---|
| User | Login name; your own session is marked |
| Role | Role within this organisation |
| Address | Address the login arrived from, as seen by the server |
| Client | Browser and operating system, shortened from the user agent (full string in the tooltip) |
| Node | Which application node accepted the login |
| Signed in | How long the session has existed |
| Last activity | When the last request came in |
| Expires | End of the session if nothing else happens |
The list refreshes every 20 seconds; the search box filters across user, address, node and client.
The token is not in there
Section titled “The token is not in there”Every row carries a fingerprint instead of the session token: a short, non-reversible value that stays the same for the same session.
That is not a detail, it is the reason for the design. The session token is the credential: whoever holds it is the signed-in user. A view that hands it out would be a list of takeable logins — including for someone allowed only to look. The fingerprint does what the display is for (tell two sessions apart, recognise one over time) without enabling that.
Limits
Section titled “Limits”Your organisation only. The filter runs on the server, before the response leaves the building — not in the interface. The view across several organisations exists only in the operator panel of the cloud edition, and that is deliberately a different authority.
A shared session store is required. The view needs Valkey
(DNSE_VALKEY_ADDR). Without it each process keeps its sessions to itself,
and the page says it cannot list them. That is more honest than an empty
table: sessions do exist, they simply are not visible.
The address column is only as good as your reverse proxy. What is shown is
what arrives at the node. If the proxy overwrites X-Forwarded-For with
$remote_addr instead of appending via $proxy_add_x_forwarded_for, you see
the previous hop. And with DNSE_TRUSTED_PROXIES set to 0.0.0.0/0 the
application believes any header it is given — then the column is an
indication, not proof.
Terminating is not part of it. The view shows, it does not intervene. To end a login, reset that user’s password.