Deploying and then trying to actually use it surfaced a dead end: /api/signup
was exempted from auth but never implemented, so a real person could sign in,
receive 403 needs_profile, and have nowhere to go. Authentication worked;
joining did not.
The route is mounted before the auth middleware, because requiring membership
to reach the route that grants membership is circular. It verifies the token
itself and then requires one of two things:
- A valid invite code. Stored hashed, optionally pinned to an address,
optionally expiring, consumed on redemption with the redeemer recorded.
- Presence in PIG_ADMIN_EMAILS. The bootstrap path, which exists because on a
fresh deployment nobody can issue an invite since nobody can sign in to
issue one.
The bootstrap path is narrow by construction: the address must be listed in
server-side configuration AND match the verified email claim on the token.
Admin rights are never read from the request body, so a crafted payload
cannot grant them.
Two behaviours worth noting. A row that was invited but never signed into is
claimed rather than rejected, binding it to the identity that just proved
ownership of the address. And a resubmitted form returns the existing user
instead of erroring, because a double-tap should be harmless.
The front end now treats needs_profile as a step in the flow rather than an
error, showing a team picker. Sending someone back to a login screen they have
already completed is a loop with no exit.
Also: the seed no longer creates the dev@localhost admin row under
NODE_ENV=production. It was unreachable (no auth subject, so nobody can sign
in as it), but an admin-flagged placeholder in a real deployment is a trap.
Verified: rejects a missing token, rejects an invalid body, claims a pre-existing
row, and is idempotent on resubmission.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
karti
7bb8835974