How it runs
What the server does at start and while it serves, the per-address limits counted in TessariDB, the JSON log and the events worth an alert, and how it stops.
At start
The server records each company in TENANTS in the region's directory,
provisions its database, registers its admin console as the client
admin-console, and makes it active. It then provisions again every company the
directory serves, those made in the console included, so a table or field a newer
build declares reaches each of them; start-up takes longer the more companies
there are. It makes a signing key for any company without one and then checks
every five minutes for keys due to rotate.
Every node re-reads which companies are active every five seconds and serves
exactly those. A company that is not active answers 404, like a name that was
never a company.
Limits
Each read (metadata, key set, UserInfo), authorization request, token request and
sign-in step is counted per client address in TessariDB, under separate limits
(see Running it). The client address is
the connection's peer, or behind a proxy listed in TRUSTED_PROXIES the
right-most X-Forwarded-For address that is not a listed proxy.
- Past the limit the answer is
429withRetry-After. - Every counted answer carries
X-RateLimit-Limit,X-RateLimit-RemainingandX-RateLimit-Class. - When the store cannot count, the request is refused with
503rather than served.
The counts are held in the store node's memory, so counting costs no disk write
and a count starts again after the node restarts or its leader changes. A
namespace declared MULTI MASTER cannot hold them, and every counted request is
then refused.
Failed sign-ins have holds of their own, described in Signing in.
Logs
Logs are JSON on standard output, filtered by RUST_LOG (info by default).
Under RUST_LOG=debug the first line, loaded configuration, is the effective
configuration with every default filled in; the store, peer and relay passwords
never appear in it, and the KEK and pepper are file paths.
A line about something that happened carries an event field. These are worth an
alert; the server sends none itself.
| Level | Event | Means |
|---|---|---|
ERROR | break_glass | the emergency operator path ran |
ERROR | audit_unrecorded | an event could not be appended to the audit trail; an issuance it belonged to was not answered |
WARN, alert on any | code_replayed | a redeemed code presented again; the refresh family it started is revoked |
WARN, alert on any | refresh_reused | a rotated refresh token presented again; its family is revoked |
WARN, alert on any | passkey_clone_suspected | a passkey's counter did not move forward |
WARN, alert on any | recovery_code_used | a recovery code was spent |
WARN, alert on any | operator_reads_high | an operator was shown 1 000 accounts in an hour |
WARN, alert on a rise | signin_rejected | a rejected sign-in credential |
WARN, alert on a rise | breach_check_unchecked | a new password set without the breached-password lookup |
WARN, alert on a rise | authorization_refused, userinfo_refused | refusals; userinfo_refused with AccessTokenUnverified covers a token whose signature, key or algorithm is not the issuer's |
WARN, alert on a rise | logout_untold, mail_abandoned | a back-channel notice or a mail given up after its retries |
Stopping
On SIGINT or SIGTERM the listeners stop accepting, the requests in flight
finish within 25 seconds, and the process exits 0.