Arnas Donauskas b013861160 feat(api): invitation create + peek + redeem endpoints ... PR 4 of the multi-user accounts series. Lands the link-only invitation flow — admin generates a shareable URL, copies it, sends it via any channel. No email service needed. API surface - GET /api/account/invitations — list pending (admin+) - POST /api/account/invitations — create (admin+) - DELETE /api/account/invitations/[id] — revoke (admin+) - GET /api/invitations/[token]/peek — public, rate-limited per-IP - POST /api/invitations/[token]/redeem — authenticated, rate-limited per-IP Token lifecycle - POST returns the plaintext token + share URL exactly ONCE in the response. We store only the SHA-256 hash. There is no endpoint that resurfaces it; if the admin dismisses the dialog without copying, the only recourse is to revoke and re-issue. - Peek and redeem take the plaintext token in the URL path, hash it in TS via `hashInviteToken`, and look up by `token_hash`. Two new SECURITY DEFINER RPCs back the cross-RLS work (migration 019): - `peek_invitation` — anonymous read. Returns a uniform JSON envelope: `{ ok, account_name, role, expires_at }` or `{ ok: false, reason: not_found|used|expired }`. The route forwards verbatim so the join page can branch cleanly. - `redeem_invitation` — authenticated. Locks the invite row `FOR UPDATE`, validates expiry/usage, refuses if the caller is already in a shared account OR their personal account has any domain rows (checked across all 11 user-creatable parent tables), then atomically moves profile.account_id + account_role, stamps the invitation accepted, and deletes the orphan personal account. Single transaction. Error contract - 22023 (invalid_parameter_value) → 400 — not_found / used / expired - 42501 (insufficient_privilege) → 401 — caller not authenticated - 23505 (unique_violation, reused) → 409 — caller's account has data, or they're already a member of the inviter's account / another shared account Rate limiting - Two new buckets in `RATE_LIMITS`: invitationPeek (30/min/IP) and invitationRedeem (10/min/IP). Belt-and-braces against token enumeration even though 256-bit entropy makes it theoretical. Uses the existing fixed-window in-memory limiter. Why no peek-then-redeem two-step on the server - Peek is read-only and idempotent; redeem locks `FOR UPDATE` so two concurrent redemptions can't both win. The peek result is cosmetic ("show me what I'm joining"); the actual write happens entirely inside the redeem RPC's transaction, so a TOCTOU between peek and redeem just means the user sees the same `{ ok: false, reason }` on the next render. Verification - `npm run lint` → 0 errors (same 20 pre-existing warnings) - `npm run typecheck` → clean - `npm test` → 366/366 pass - `npm run build` → succeeds; the 4 new routes register as ƒ Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-05-31 17:32:46 +03:00
..
migrations	feat(api): invitation create + peek + redeem endpoints	2026-05-31 17:32:46 +03:00