Authentication

Admin → Authentication has four tabs: Local Accounts, Google, Discord and Custom Providers. One session model sits behind all of them — a web cookie, a mobile bearer token and an SSO sign-in all produce the same session.

Local accounts

Username and password sign-in is always enabled and cannot be turned off. It is how you manage accounts and how SSO identities get linked in the first place, so there is no configuration on this tab beyond that statement.

Two-factor is a per-account, opt-in TOTP code, set up by each person under Account in the sidebar. Nobody can enable it on someone else’s behalf, and staff accounts are the ones worth insisting on.

SSO providers

Google and Discord each need a client ID and secret from that provider’s developer console; Custom Providers takes any OAuth2/OIDC issuer. Secrets are encrypted at rest with SECRET_ENC_KEY and are never returned to any client.

SSO is link-only, by policy

An external identity can only sign in to an account it is already linked to. Signing in with Google does not create an account, ever. People link a provider themselves from their own account screen, and that link is what grants the access — so a stranger with a Google account is still a stranger.

Configuring Google here also unlocks email delivery, which reuses the same OAuth client — see Notifications and email.

Trusted devices

A second factor that asks on every sign-in on the same laptop trains people to click through it. A device can be remembered after a successful two-factor challenge, and the trust rides the browser’s own cookie jar — including the in-app browser tab the Android app opens for SSO, which is why signing in there does not ask again.

Trust is per device and revocable, and it survives signing out: signing out ends a session, not the statement that this machine is yours.

What keeps the automated traffic out

Four layers, all on by default:

• Rate limiting and backoff on the login routes, so a password guess costs time.
• A honeypot field that a human never fills in and a naive bot always does.
• Bot scoring, which accumulates points against an address for behaviour no human produces, and bans it automatically past a threshold.
• IP bans from that scoring.

Admin → Web Bot Activity shows the live state: currently banned addresses with their score and expiry, and the recent events with the reason, path and points that produced them. It is deliberately read-only apart from an emergency unban — there is nothing to tune here, and the panel exists so that a legitimate user locked out by their office’s shared address can be let back in.

The scoring state is in memory, and resets when the server restarts

So a restart clears every automatic ban. That is a reasonable escape hatch when you have locked yourself out, and a reason not to treat this list as a permanent record.

Getting locked out

Two situations worth knowing before they happen at three in the morning:

• Your address is banned. Restart the app container — the in-memory state goes with it.
• You lost your second factor. Use one of the recovery codes issued when you enabled it. If those are gone too, another administrator opens Users → View on your account and presses Reset two-factor, which turns TOTP off, revokes your trusted devices and clears your recovery codes so a password sign-in works again. That is the practical argument for a site never having exactly one admin.

The same screen lists an account’s trusted devices and revokes them individually or all at once — the right response to a lost or stolen laptop, and something to reach for before resetting the whole second factor.