Niklas Ye
d827ceedff
First half of #7. Until now the only way to get an account was for somebody who already had one to create it, and the login page told people to "ask an admin" -- workable for one operator, impossible for a team. Two modes, chosen by an administrator in the settings table: invite_only, which is the default, and open. A third domain-restricted mode was considered and dropped, because with no email in this server there is nothing to verify an address against and it would only check the domain of a string somebody typed. The default is the closed door. An install that gets a public hostname before anybody has thought about sign-up should not be collecting accounts from the internet, and the failure mode of a typo in the setting is invite_only rather than open. An invite is a link, not an email. Adding SMTP to send one message would be a subsystem to run, secure and monitor; the person inviting sends the link however they already talk to the person they are inviting. A link carries the team and the role, because an account in no team sees an empty queue and can be paged by nobody -- that is not a state to invite somebody into. Links are single-use by default, expire after seven days, and can be revoked before that: a link that works forever is a credential nobody remembers issuing, sitting in a chat log. The uses counter is incremented inside the sign-up transaction and guarded by `uses < max_uses`, so two people redeeming the last use at once cannot both get in. GET /api/signup reports the mode and whether a link is usable, so the form can say "this link has expired" before somebody picks a password rather than after. It gives one answer for expired, revoked, used up and never existed: telling a stranger which it was tells them something about links they do not hold. Sign-up signs you in. The alternative is a form that says "now go and log in", which is the same credential typed twice. login and signup now share startSession rather than each minting a cookie. Rate-limited per address on its own limiter, not login's: a burst of sign-ups must not lock somebody out of logging in. The settings table grew a second shape for this. It held only durations; signup_mode is a word from a fixed list, so the admin endpoint now validates everything before writing anything -- a request that sets two settings and gets one wrong changes neither. Still to come in #7: the sign-up and invite-redemption pages, the first-run checklist, and the in-app integration instructions. The schema carries onboarding_dismissed_at for the checklist already. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7
50 lines
2.4 KiB
SQL
50 lines
2.4 KiB
SQL
-- Self-service sign-up, and the invite links that make it useful.
|
|
--
|
|
-- Until now the only way to get an account was for somebody who already had one
|
|
-- to create it, and the login page told people to "ask an admin". That is a
|
|
-- workable arrangement for one operator and an impossible one for a team.
|
|
--
|
|
-- An invite is a link, not an email: this server has no SMTP and adding it to
|
|
-- send one message would be a new subsystem to run, secure and monitor. The
|
|
-- person inviting sends the link however they already talk to the person they
|
|
-- are inviting.
|
|
CREATE TABLE invites (
|
|
id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
|
|
|
|
-- SHA-256 of the raw token, like api_keys, the integration keys and the
|
|
-- acknowledgement tokens. A leaked database hands nobody an account.
|
|
token_hash TEXT NOT NULL UNIQUE,
|
|
|
|
-- Which team the invitee lands in, and as what. An invite always names a
|
|
-- team: an account in no team sees an empty queue and can be paged by
|
|
-- nobody, which is not a state to invite somebody into.
|
|
team_id BIGINT NOT NULL REFERENCES teams(id) ON DELETE CASCADE,
|
|
role TEXT NOT NULL CHECK (role IN ('owner', 'member')),
|
|
|
|
created_by BIGINT REFERENCES users(id) ON DELETE SET NULL,
|
|
created_at BIGINT NOT NULL DEFAULT FLOOR(EXTRACT(EPOCH FROM now()))::bigint,
|
|
|
|
-- Invites expire. A link that works forever is a credential nobody
|
|
-- remembers issuing, sitting in a chat log.
|
|
expires_at BIGINT NOT NULL,
|
|
|
|
-- Single-use by default: max_uses 1. A team onboarding six people at once
|
|
-- can raise it rather than minting six links.
|
|
max_uses BIGINT NOT NULL DEFAULT 1 CHECK (max_uses > 0 AND max_uses <= 100),
|
|
uses BIGINT NOT NULL DEFAULT 0,
|
|
|
|
-- Revoked by hand, separately from expiry, so "this link is no longer
|
|
-- wanted" and "this link timed out" stay distinguishable in the listing.
|
|
revoked_at BIGINT
|
|
);
|
|
|
|
CREATE INDEX invites_team_idx ON invites(team_id);
|
|
|
|
-- Who redeemed which invite. Kept after the invite is gone — the answer to "how
|
|
-- did this account get here" should outlive the link that made it.
|
|
ALTER TABLE users ADD COLUMN invited_via BIGINT REFERENCES invites(id) ON DELETE SET NULL;
|
|
|
|
-- Where a person is in the first-run checklist, so it can be resumed and
|
|
-- dismissed rather than nagging forever. One row per user, created on demand.
|
|
ALTER TABLE users ADD COLUMN onboarding_dismissed_at BIGINT;
|