Session revocation

Lazysite sessions are signed cookies with a 24-hour lifetime. Each login also gets a short random session id, so individual sessions can be listed and signed out from the manager without touching anyone else's.

What the operator sees

Manager > Sessions lists every live session:

• user
• signed-in time
• IP address
• device (a sanitised browser user-agent string)
• a "this session" marker on the operator's own session

Only live sessions appear: expired, revoked and signed-out-everywhere sessions are filtered out, never shown as a raw history. The listing comes from a small registry (lazysite/auth/sessions.jsonl, one line per login, self-pruned after 24 hours). The registry is advisory - losing it degrades the Sessions page, never authentication, and a registry write failure never blocks a valid login.

Revoking

Two controls per row, plus one big lever:

• Sign out - ends that one session. Its session id goes into the revoked set (lazysite/auth/revoked.json).
• Sign out everywhere - ends all of a user's sessions by recording a per-user cut-off time; every cookie issued before that moment fails, including legacy cookies from before session ids existed. The account itself is untouched - the user can sign straight back in.
• Rotate the auth secret - invalidates every session on the site at once (the everyone-out option, also offered on the page).

Session listing and revocation require the Users & groups permission (manage_users) and are available to signed-in managers only - API token clients cannot reach these actions at all. Every revocation is logged.

What a revoked session experiences

Enforcement happens in one place: the auth wrapper's cookie verification, on the very next request. A revoked cookie simply stops verifying, so the request is treated as unauthenticated - public pages still render, and the manager or any protected page asks for a fresh sign-in. There is no grace period and nothing the browser can do with the old cookie.

Notes

• Revocation entries self-prune after 24 hours (once the cookies they match have expired anyway), so the file never grows
• An absent revoked-list costs a single file check per request; a corrupt one is treated as empty with a loud warning - a damaged file can never lock everyone out
• The logout button uses the same mechanism, so signing out really invalidates the session server-side rather than just clearing the cookie