Authentication

Signing in to Chinaski, how sessions work, and what it takes to invalidate one. Everything here covers the admin application; API access by machines is a separate mechanism noted at the end. (This page sticks to login and sessions; the permissions model is covered by its own page.)

Logging in

You sign in with a username and password at the login screen. A few things worth knowing are working behind the scenes:

Empty submissions are rejected before anything else happens.
Password checks take the same amount of time whether or not the username exists, so the site never hints at which accounts are real.
A suspended account is turned away with the same generic message (suspension is immediate; see below).
Each successful sign-in creates a fresh session from scratch (nothing carries over from the previous session) and the sign-in is recorded in the login history that admins can view.

If you tick Remember me, the session lasts 30 days instead of the usual 8 hours.

Lockouts

Failing to log in repeatedly from the same IP address triggers escalating lockouts:

5 consecutive failures → 60-second lockout
10 → 5 minutes
20 → 30 minutes

While locked out, all further attempts are rejected outright and the remaining wait is shown. The counters survive restarts and reset themselves after 10 minutes of inactivity. These thresholds are fixed; they can’t be changed in the admin area. What admins can configure (Settings → Security, failure threshold) is a separate alert: when failed or blocked attempts in any 10-minute window reach that number, a warning is written to the event log.

Sessions

A session is anchored in two places at once: a signed, secure, HttpOnly cookie, and a server-side session record containing a hashed random session token, IP address, browser identifier, and expiry.

Because the server keeps a record, sessions are validated on every request, not just at login:

Role changes take effect immediately. Your role is re-read from the account record on every request, so a demotion or promotion does not require a re-login.
Deleting an account ends its sessions immediately.
A expired or revoked token ends the session at once with “Your session has been revoked.”
Sessions expire on their own after 8 hours (or 30 days with Remember me). SSO sessions are always 8 hours.
All admin forms include CSRF protection, so links or third-party pages can’t submit content actions on your behalf.

Logging out and invalidating sessions

Sign out ends the current session: the server-side record is deleted and the cookie expires right away. The logout page works even when you’re already signed out, so it never dead-ends.
Log out everywhere (your account page) invalidates every session except the one you’re using right now, so you aren’t kicked out of your own current tab; other devices and browsers are cut loose.
Suspension (admin action) invalidates that user’s sessions immediately. It doesn’t wait until their next sign-in.
Changing someone’s password (admin action) also deletes all their sessions, so the new password takes effect on the next sign-in.

Password expiry

If password expiry is configured (Settings → Security), the check runs at login: when your password is older than the configured number of days you’re taken straight to the password-change page with a notice. Until you change it, every other admin page bounces you back there, the only pages that stay reachable are the password change itself and signing out.

Roles and access gates

What a signed-in user can do is governed by the permissions system, see the Permissions page. The same gate that checks permissions also revalidates the session each time, so revoking access always happens on the next request rather than at some later re-login.

Password resets

Password reset tokens (where configured) all expire within 7 days at the very latest, used or expired tokens are cleaned up automatically. Alternatively an admin can set a new password for you directly; that also invalidates your sessions immediately.

Machine access (API)

Requests sent with an API key header skip the browser session entirely: they are authenticated by the key instead, and the header must present write permission for any request that modifies content. Read-only keys get access to fetching; a CSRF exemption only applies to those API-key requests, never to browser sessions.

First boot

A fresh install creates an admin account with a placeholder password and redirects all requests to a first-run setup page until a real password is set. Once a password is set (12+ characters with upper, lower, and digit), the setup page goes away for good.