Mirrors the pattern sitesvc already proves: 32 random bytes, only the
SHA-256 hash stored, a 24-hour expiry, and the token cleared on use -- so a
leaked database yields no working links.
Unverified login returns a distinct "verify your email address first" rather
than the generic error. The address is already known to be theirs, so there
is nothing to disclose and that is the only useful thing to say.
Licence blobs are emailed inline. A blob is signed public data, not a
secret: it is useless on any instance other than the one it names.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cloud customers sign in with the control-plane credentials they already
hold, so there is no second password to manage. Two accepted consequences,
documented at the handler: their control-plane password now also unlocks
billing, and only role owner may sign in -- admin and member are refused
because billing is an owner concern.
A self-hosted customer_users row wins over a control-plane user with the
same address, so the precedence is chosen rather than emergent.
Adds the reads of control users this needs; the write surface is still one
UpdateOne on instances.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
One Redis session store and one cookie for all three identities. Staff
login returns the same error for every failure mode and spends a bcrypt
comparison against a dummy hash when no user exists, so neither the message
nor the timing confirms which addresses have accounts.
Staff users are created only by adminctl. There is no signup endpoint: a
licensing authority that can be joined over the internet is not one.
Pins gin and go-redis to the versions server/ already uses rather than the
latest tidy would pick.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mrhid6andClaude Opus 5