3 Commits

Author	SHA1	Message	Date
Niklas Ye	774fdfcaa8	internal/api: unify human/service-account authz into one Caller type ... ctxUser/ctxTeams (human) and ctxServiceAccount (+ a synthetic ctxTeams entry, service account) used to be two parallel, un-unified context representations -- every authz predicate had to remember which one(s) it needed, and every place that forgot either wrongly 403'd a service account (terdut-server#23, terdut-operator#3), crashed on an unchecked zero-value user id, or silently no-op'd. New internal/api/caller.go collapses both into one Caller, stored under one ctxCaller key by serveAs/serveAsServiceAccount; every existing predicate (userFromContext, callerTeamIDs, callerRole, callerIsAdmin, isInstanceServiceAccount, AdminOnly, requireSelfOrAdmin, requireTeamOwner, OperatorModeBlock) now reads through it, with identical behavior for every untouched call site (alerts.go, incidents.go, schedule.go, stats.go, etc.) -- confirmed by the full existing suite passing unchanged. Four real fixes land alongside the refactor, not just the restructuring: 1. callerMayManageServiceAccount gains the one load-bearing branch this exists for: an instance-scoped service account may now manage (mint or revoke a key on) any team-scoped account, not only a human admin, that team's human owner, or the account itself. handleCreateServiceAccount already let an instance-scoped caller *create* a team-scoped account for any team; adopting or rotating one it didn't just create in the same call -- terdut-operator's own documented crash-window recovery -- had no equivalent permission and 403'd forever. Closes terdut-operator#3. 2. handleCreateInvite wrote a service-account caller's zero-value user id straight into invites.created_by (nullable, but never passed as nil), which foreign-key-violates against users(id) -- a 500, not success, for any team-scoped service account minting an invite. Fixed the same way handleCreateServiceAccount already handles the analogous case. Found live while verifying this change, not filed separately since it's fixed in the same place it was found. 3. handleMe and handleTestNotification 500'd for a service-account caller (fetchUser/the ntfy_topic lookup against a zero-value user id that matches no row); handleDismissOnboarding silently no-op'd (UPDATE ... WHERE id = 0). All three now call Caller.AsHuman() and return an explicit 403 ("this endpoint is for human accounts only"). 4. Ratifies, rather than further narrows, two capabilities a team-scoped service account already had by construction and this document's own text once called "a gap acknowledged rather than closed": owner-equivalent reach over membership/invites, and minting another service account for its own team. terdut-operator's new TerdutTeam invite-minting feature is about to depend on the first one, so this makes it documented, tested, intentional behavior instead of an accident nobody was supposed to rely on. AdminOnly/requireSelfOrAdmin are unchanged in effect: still human-only, forever, for every scope of service account -- confirmed by TestAdminOnly_RefusesEveryServiceAccountScope. terdut-server#23's named routes (POST /api/users, PUT /api/admin/settings) were never the right thing to widen; its real fix is the terdut-operator invite feature, recorded in SERVICE-ACCOUNTS.md's "What this unblocks" and closing that issue once it ships. SERVICE-ACCOUNTS.md amended in place (not a new file, its own established convention) to describe the as-built Caller model, correct its own aspirational claim about AdminOnly that TEAM-LOOKUP.md had already flagged as not matching shipped code, and record all of the above.	2026-10-02 21:52:43 +02:00
Niklas Ye	b39aac36b7	Add the sign-up page and the first-run checklist ... Second half of #7. The API could create accounts from invite links since the last change; this is the part somebody can actually use. /signup is the one route that works without a session. It asks the server what it may offer before showing anything: an invite link that is good names the team it leads to, a link that is not says so before somebody picks a password rather than after, and an invite-only server with no link says that instead of presenting a form it will refuse. The login card only offers "create one" when sign-up is open, so the door nobody can walk through is not advertised. Signing up signs you in and lands on the queue, because the alternative is a form saying "now go and log in" about the credential just chosen. The checklist is the other half. Four things have to be true before an alert reaches a phone -- a notification topic, somebody on the rota, an alert source, and an alert that has actually arrived -- and on a fresh install none of them are. It sits above the queue until they are. It is computed from the data rather than from stored progress: a topic is set or it is not, an integration exists or it does not. That means it cannot claim a step is done when it is not, and it comes back by itself if somebody deletes their integration a month later. The only stored state is the dismissal, which is per user and not per browser -- finishing on a laptop should not leave the phone nagging. The topic step is the only one the checklist can finish itself, and the only proof that counts is a phone buzzing, so there is a test push. POST /api/me/notify/test publishes directly rather than through the outbox, which requires an incident this deliberately does not have. Its failure is the useful part: a wrong topic, a rejected token and an ntfy that is down all look identical from the phone, which is silence, so the error comes back to the browser instead. Verified against a live server with a real ntfy stand-in, the whole path: an owner mints an invite, the sign-up page reports it valid and names the team, the invitee signs up and is signed in as a member of that team, the checklist's four questions answer correctly on a fresh install, a test push is refused with no topic and delivered with one -- "PAGED terdut-owner | terdut test" -- and the dismissal survives a reload. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7	2026-09-21 10:47:15 +02:00
Niklas Ye	d827ceedff	Add self-service sign-up and invite links ... 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	2026-09-21 09:06:48 +02:00