Skip to content

Admin Sessions

The Admin Sessions page lists every admin, reseller, and staff account that is currently logged in to the panel. Each row is one authenticated login (JWT) session. You can revoke any session to immediately force that user to sign in again.

Sessions are recorded at login time and stored in Redis. The list is sorted newest-login-first.

Sidebar -> Admin Sessions. Direct URL: /admin-sessions.

This is an admin-only page. The backend route group requires the admin_sessions.manage permission, and the frontend route is gated to admin users.

A single table of live sessions. It auto-refreshes every 10 seconds, and relative timestamps tick locally every second between refreshes. A Refresh button forces an immediate reload.

When nobody is logged in, the page shows an empty state. Note that the list reflects logins recorded since the last API restart.

ColumnSourceNotes
Statuslast_seenLive-activity dot. Green “active now” if seen in the last 60 s (the auth middleware bumps last_seen at most once every 30 s), amber if within 5 minutes, gray otherwise. Shows “never seen” if the session has no recorded activity.
UserusernameThe account’s username. The caller’s own session is tagged with a blue YOU badge.
Typeuser_typeColor-coded badge: admin (red), reseller (purple), other staff types (gray).
IPip_addressThe client IP the session logged in from.
Browser / OSuser_agentThe user agent parsed into a compact “Browser / OS” label (e.g. Chrome 124 / Win 10/11).
Logged inlogin_atRelative time since login.
Expires inexpires_atTime remaining until the JWT expires (e.g. 7 h, 2 d 4 h), or “expired”.
ActionRevoke button, except on your own session (shows “current session”).

Each session is identified internally by a token hash (token_hash), a 16-character SHA-256 prefix of the JWT. The raw token is never exposed.

Click Revoke on any session that is not your own. A confirmation modal names the user and their type and warns that they will be logged out on their next request and will have to log in from scratch.

How it works: revoking deletes the session’s record from the active-sessions store. The auth middleware treats the presence of a session record as the live-ness signal — it rejects any request whose token hash is not in the active-sessions set. So once the record is gone, the user’s existing token stops being accepted on its very next request. There is no way to reconstruct the raw JWT from the stored hash, which is why revocation works by removing the session record rather than blacklisting a specific token string.

Admin actions taken against other users’ sessions are intended to be traceable via the audit trail.

Force a departed staff member off immediately

Section titled “Force a departed staff member off immediately”
  1. Find their username in the list.
  2. Click Revoke on each of their sessions (a user may have more than one row if they are signed in on multiple devices/browsers).
  3. Confirm. They are logged out on their next request and must sign in again.
  1. Scan the IP and Browser / OS columns for an unfamiliar location or device.
  2. Check Logged in and Status to see when the session started and whether it is still active.
  3. If it does not belong, Revoke it, then have the account’s password changed.
  1. Open the page and look at the Status column — green dots are active within the last minute.
  2. The list auto-refreshes every 10 seconds; use Refresh to force an immediate update.
PermissionEffect
admin_sessions.manageRequired by the backend to list and revoke sessions. The page is admin-only in the panel.
  • Sessions — the separate, unrelated page for live subscriber PPPoE / hotspot sessions from the RADIUS radacct table. Use that page to disconnect a customer’s internet connection.
  • Users & Permissions — manage the admin/staff accounts that appear here.
  • Resellers — manage the reseller accounts whose login sessions appear here.
  • Audit Log — record of admin actions, including session revocations.