Repository navigation
feat(invites): GDPR + zero-trust drive invites - #1266
Closed
2witstudios wants to merge 21 commits into
Closed
2witstudios wants to merge 21 commits into
2witstudios wants to merge 21 commits into
Conversation
Add pending_invites table for GDPR + zero-trust drive-invite refactor — token hash, email, drive, role, inviter, expiresAt, consumedAt, createdAt. Partial unique index on (driveId, email) where consumedAt IS NULL rejects duplicate active invites at the DB level. Both FKs cascade on delete so abandoned tokens cannot be replayed against re-created drives or invites issued under deleted-inviter authority. Adds tasks/drive-invite-gdpr-zero-trust.md decomposing the refactor into 12 atomic TDD-gated subtasks; this commit lands the first one (schema + migration). The epic stops invite-send-time users-row creation, removes the magic-link-as-invite path, and routes invitees through standard signup/login with affirmative ToS acceptance. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
isInviteExpired, isInviteConsumed, isEmailMatchingInvite — pure functions with destructured object args, no DB or Date.now() calls. Email comparison normalizes case + surrounding whitespace, matching the invite endpoint's existing lookup behavior. Treats expiresAt === now as expired (>=) so 'expires at T' means invalid from T onward. 11 vitest cases cover both branches plus boundaries (one-ms before/equal/one-ms after for expiry; case-only, whitespace-only, both, negative for email). Task 2 of the drive-invite GDPR + zero-trust epic. These predicates back the upcoming invite-token verifier and the acceptInviteForNewUser / acceptInviteForExistingUser asyncPipes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
createInviteToken / verifyInviteToken in packages/lib/src/auth/invite-token.ts. Reuses generateToken (CUID2 + SHA3-256) and secureCompare (timing-safe) from existing auth utilities — no new hashing or compare primitive introduced. Tokens are page-load credentials only with zero auth power: a session is never mintable from an invite token. Raw token is returned to the caller for one-time URL embedding; only the SHA3-256 hash persists at rest (mirrors session and verification-token storage). Default expiry 48h. 9 vitest cases cover prefix, hash determinism, default + custom expiry, distinctness across calls, positive verification, and four false-branch cases (wrong token, empty token, empty hash, length mismatch). Task 3 of the drive-invite GDPR + zero-trust epic. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds createPendingInvite, findPendingInviteByTokenHash, markInviteConsumed, findActivePendingInviteByDriveAndEmail to driveInviteRepository. Single-query joined lookup returns driveName + inviterName so the consent page renders without an N+1. markInviteConsumed runs an atomic conditional UPDATE — WHERE id = X AND consumedAt IS NULL — so two concurrent acceptance attempts can never both succeed (mirrors acceptPendingMember's pattern). Returns false when zero rows match. Also exposes ./schema/pending-invites in @pagespace/db package.json so consumers can import the table; pending-invites schema is rebuilt as part of the same task. findPendingMembersForUser is intentionally NOT removed in this task — its sole caller (acceptUserPendingInvitations) is referenced from 9 production routes plus their tests, and ripping it out without simultaneously wiring acceptInviteForExistingUser would break the build. The deprecation lands atomically with task 10/13. Task 4 of the drive-invite GDPR + zero-trust epic. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
POST /api/drives/[driveId]/members/invite no longer creates a users row at invite-send time. Replaces createMagicLinkToken + driveMembers(acceptedAt:null) with createInviteToken + pendingInvites for the email path. Email URL changes from /api/auth/magic-link/verify?token= to /invite/<token>. Default expiry shortens from 7 days to 48h via createInviteToken's default. Rollback path now targets the pendingInvites row (deletePendingInvite, added to the repository) instead of a driveMembers row. Verified-existing-user fast path through handleUserIdPath is untouched. Unverified existing users continue to route through the invitation flow per the orphan-cleanup boundary. logMemberActivity is intentionally NOT called on the pending-invite path: its targetUserId field (used as the activity log resourceId) has no value when no users row exists. auditRequest captures the event keyed on email instead. The activity logger resumes once the invitee accepts and a real user materializes. Response field rename: existingMemberId -> existingInviteId on the 409 conflict path; memberId -> inviteId on the kind:invited response. Pre-release surface, hard cutover per project rule. The resend route still uses magic-link and is logically broken post-cutover; its rewrite pairs naturally with task 12's data migration. Task 5 of the drive-invite GDPR + zero-trust epic. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
New server-rendered consent screen at /invite/[token]/page.tsx. Resolves the raw token via resolveInviteContext (hashes the token, looks up the pending_invites row joined to drive + inviter, derives isExistingUser from the email's tosAcceptedAt status). Renders inviter name + drive + role + invited email + ToS/Privacy links + a single CTA. New users go to /auth/signup?invite=<token>; existing users (tosAcceptedAt IS NOT NULL) go to /auth/login?invite=<token>. Invalid/expired/consumed tokens render an opaque 'this invite is no longer valid' card — never redirect, which would leak that the token ever existed. The page awaits Next.js 15 params Promise; destructuring directly would be a silent bug. Adds findUserToSStatusByEmail to the repository so isExistingUser can be derived in a single query without disclosing other PII (no name, no last-login). Pure resolver logic is fully unit-tested (7 vitest cases: NOT_FOUND, hash-before-lookup, CONSUMED, EXPIRED, existing+ToS, no-user, user-without-ToS-orphan). Task 6 of the drive-invite GDPR + zero-trust epic. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the hardcoded acceptedTos:true at PasskeySignupButton.tsx:111 with a real form field. New checkbox above the submit button labeled 'I agree to the Terms of Service and Privacy Policy' (links open in a new tab). Submit button is disabled until checked, and a guard before the registration request blocks any non-checkbox bypass attempts. Removes the duplicate 'By signing up, you agree to our Terms' footer from the signup page — the checkbox is the binding gate; the footer was decorative and had no enforcement value. Server-side validation already exists at signup-passkey/route.ts:28 (zod refine acceptedTos === true returns 400) and at passkey-service.ts:88. The previous client behavior silently sent true regardless of user intent — this commit closes that GDPR gap so consent is real, not implied. Task 7 of the drive-invite GDPR + zero-trust epic. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Splits /auth/signup into a server component (page.tsx) that resolves the invite token via resolveInviteContext and a client component (SignUpClient.tsx) that renders the form. When the URL carries ?invite=<token> and resolution succeeds, the page renders a banner ('X invited <email> to join Y') and pre-fills + locks (disables, not just readOnly) the email field via the new lockedEmail prop on PasskeySignupButton.
Failed resolution still renders signup — signup is independent of invite acceptance per the epic. A stale invite surfaces post-signup as a non-blocking dashboard toast in task 9. The locked email gate prevents the email-mismatch acceptance vector even if a user attempts to override the disabled input via DevTools (server-side acceptance pipe re-validates in task 9).
Task 8 of the drive-invite GDPR + zero-trust epic. Out of scope: signing out a logged-in user with a different email than the invite — handled as a follow-up after the targeted post-login pipe lands (task 10).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
New acceptInviteForNewUser({token, userId, userEmail, now}) at apps/web/src/lib/auth/invite-acceptance.ts. Composes the pure predicates (isInviteConsumed, isInviteExpired, isEmailMatchingInvite) with the repository's atomic single-use markInviteConsumed and createDriveMember inserting a row with acceptedAt=now. Returns a discriminated result (TOKEN_NOT_FOUND, TOKEN_EXPIRED, TOKEN_CONSUMED, EMAIL_MISMATCH) instead of throwing — boundaries convert the result into a UI signal.
Wires end-to-end: page.tsx forwards ?invite=<token> to SignUpClient; PasskeySignupButton sends inviteToken in the signup-passkey request; signup-passkey/route.ts runs acceptInviteForNewUser after session creation. Acceptance failures are NON-fatal — signup itself succeeds, the session stays alive, and the dashboard receives a non-blocking inviteError query param. Successful acceptance routes the user to the joined drive instead of the freshly-provisioned getting-started drive.
Repository's findPendingInviteByTokenHash now also returns invitedBy so the new pipe can populate driveMembers.invitedBy without a second query. Existing acceptUserPendingInvitations broad sweep is left in place — it's removed atomically with the rest of the legacy code in task 10. 7 new vitest cases cover all four error variants, the markInviteConsumed race, the happy path, and case+whitespace email normalization.
Task 9 of the drive-invite GDPR + zero-trust epic.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
acceptInviteForExistingUser mirrors acceptInviteForNewUser but adds an ALREADY_MEMBER guard so re-clicking an old invite link does not silently re-add an already-accepted user. Returns the same result shape so callers handle both pipes uniformly. New /invite/[token]/accept GET handler is the single chokepoint for the 'Sign in to join' path: requires a live session via authenticateRequestWithOptions; redirects unauthenticated users to /auth/signin?invite=<token>&next=/invite/<token>/accept so they bounce back here post-login; runs acceptInviteForExistingUser and redirects to the drive on success or to the dashboard with an inviteError query param. The consent page's existing-user CTA now points here. Decoupling rationale: every auth method (passkey, magic-link, OAuth) lands at the same gateway, so the acceptance pipe doesn't need to be threaded through 9 separate post-auth routes. The next task replaces the legacy broad sweep in those routes (acceptUserPendingInvitations) with deletion. Task 10a of the drive-invite GDPR + zero-trust epic. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Magic-link service no longer auto-creates users. createMagicLinkToken returns NO_ACCOUNT_FOUND for unknown emails (handled by the same enumeration-safe response path that already exists in /api/auth/magic-link/send). Magic-link is now an existing-account login mechanism only; account creation moved exclusively to /auth/signup with affirmative ToS acceptance per the GDPR + zero-trust epic. The user auto-create branch in magic-link-service.ts is deleted, the isNewUser field disappears from CreateMagicLinkResult and VerifyMagicLinkResult, and the magic-link verify route hard-codes isNewUser=false at the destructure (every verified user is now by definition existing). acceptUserPendingInvitations is downgraded to a deprecated no-op shim. The function name + signature are preserved so the post-login-acceptance-coverage gate keeps enforcing the 'every auth route runs this hook' contract and the 9 existing callers (apple/native, apple/callback, magic-link/verify, passkey/authenticate, google/native, google/one-tap, google/callback, signup-passkey, mobile/oauth/google/exchange) continue to compile — but the body returns []. The underlying findPendingMembersForUser broad sweep is deleted from the repository, eliminating the userId-keyed acceptance vulnerability surface. Pending invites are now consumed exclusively at /invite/[token]/accept (existing users) and /api/auth/signup-passkey (new users). Repository's findActivePendingMemberByEmail (legacy email-keyed pending lookup against drive_members) is also deleted — pending state no longer lives in drive_members. Magic-link drive provisioning tests are simplified: provisioning happens at /auth/signup, not on magic-link verify, so the 'new user provisioning' tests collapse into a single 'never provisions' contract. Tasks 10b + 11 of the drive-invite GDPR + zero-trust epic. The shim's removal and the deletion of acceptUserPendingInvitations callsites is paired with task 12's data migration. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
packages/db/src/migrate-pending-invites.ts ports legacy pending state into the new model: every drive_members row with acceptedAt IS NULL is replaced by a fresh pending_invites row (new tokenHash, 48h expiry from now, original (driveId, role, invitedBy) preserved, email pulled from the joined users row). Each port runs in a transaction so a partial failure cannot leave a row in both tables. After porting, the script deletes orphan users — rows that have no passkeys, no tosAcceptedAt, no emailVerified, and no remaining drive_members reference. The check is conservative: any auth credential or any verified email leaves the row intact, even if the user has otherwise dormant data. The new tokens are generated server-side; no email is sent. Admins re-send invites through the normal /api/drives/[driveId]/members/invite flow so recipients receive the new /invite/<token> URL via the standard delivery path. Idempotent: re-running against migrated data finds zero rows to migrate and zero orphans to delete. Run once during cutover with: pnpm --filter @pagespace/db migrate-pending-invites. Task 12 of the drive-invite GDPR + zero-trust epic. This closes the loop: new invites use pending_invites end-to-end (tasks 1-11) and any legacy data lands cleanly on the new model (this task). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
Warning Rate limit exceeded
To continue reviewing without waiting, purchase usage credits in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (40)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 812f0a1b18
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The previous migration created pending_invites rows with a freshly-generated tokenHash but no raw token — so the recipient could never receive a usable URL, and the partial unique index on (driveId, email) WHERE consumedAt IS NULL would block admins from re-inviting because findActivePendingInviteByDriveAndEmail would return 409. The original raw token was never persisted (only the SHA3-256 hash lived in verification_tokens, which the magic-link service has rotated through normal expiry), so there is no path to re-issue a valid invite from the legacy data alone. The migration is now a clean wipe: delete drive_members rows with acceptedAt IS NULL, delete users with provider='email', no passkeys, no tosAcceptedAt, no emailVerified, and no remaining drive_members. Admins re-invite through the normal flow which produces a valid /invite/<token> URL. Idempotent. Conservative orphan check leaves any user with auth credentials, verified email, ToS acceptance, or accepted membership intact. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two P1 issues from automated review: (1) findActivePendingInviteByDriveAndEmail now also filters expiresAt > now. Without this, an expired-but-unconsumed pending_invites row would 409 indefinitely on every re-invite to the same (drive, email) pair, breaking the 48h expiry contract — admins could never re-invite that address until manual cleanup. (2) acceptInviteForExistingUser handles legacy drive_members rows with acceptedAt=null. The pre-cutover schema parked pending state on drive_members keyed by userId; task 12 wipes those, but during the deploy window a ghost row could exist. Previously the existing-member check (acceptedAt !== null guard) skipped these rows, so the function would consume the invite token and then fail on the unique (driveId, userId) constraint when inserting the accepted membership — leaving the user stuck. The function now deletes the legacy row before inserting the fresh accepted membership. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wraps invite consumption + driveMembers insert in a single Drizzle transaction via the new repository helper consumeInviteAndCreateMembership. If the membership insert fails (e.g. unique constraint, transient DB error), the invite consumption is rolled back so the user can retry — previously a mid-pipe failure would leave the token consumed with no membership and the user stuck. The legacy pending drive_members deletion now also runs inside the same transaction. Both pipes (acceptInviteForNewUser, acceptInviteForExistingUser) compose through this single helper, removing the two-step consume-then-insert pattern that allowed split-brain failures. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Magic-link no longer creates new users (NO_ACCOUNT_FOUND for unknown emails). The send route stopped logging/auditing isNewUser when the auto-create branch was removed; the test assertions now match. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds three unit tests against the joined-mock pattern used by the rest of the repository test file: returns the timestamp for a ToS-accepted user, returns the row with tosAcceptedAt=null for legacy orphans (so the resolver correctly surfaces them as new-users), and returns null when the email has no users row. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two requests can pass the findActivePendingInviteByDriveAndEmail check simultaneously (no row exists), then race on the partial unique index when both try to insert. The route now catches the unique-constraint violation and returns 409 ('already pending') instead of letting the outer try/catch surface a generic 500.
New test covers the path. The race window is small (rate limiter caps invite frequency per (drive,email) pair) but a 500 here would be misleading and unhelpful.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The lib-level acceptedAt-gate coverage test scans every lib file that mentions driveMembers and requires either an isNotNull guard or an explicit allow-list entry. invite-acceptance.ts only mentions driveMembers in a docstring (delegates to the already-allow-listed repo helper), so add a justified allow-list entry rather than break the gate. Also tightens the existing repository allow-list reason now that pending invitation state has moved out of drive_members. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Owner
Author
|
@codex review the latest commit (a4bf230) — addresses both prior P1 findings (active-pending now filters expiresAt; legacy pending drive_members rows now cleaned up inside the transactional consume+insert helper) plus a few proactive hardenings: race-window 409 on the partial unique index, and the gate-coverage allow-list for invite-acceptance.ts. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a4bf2307e6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Updates the two unit tests in magic-link-service.test.ts that exercised the auto-create branch removed by the GDPR + zero-trust epic. The 'should create new user when email not found' test now asserts NO_ACCOUNT_FOUND and that no users insert occurs. The 'should handle unique constraint violation (race condition)' test asserts the opposite: there is no race because there is no insert. Closes the unit test failure observed on CI. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Codex P2 finding: a file that only mentions driveMembers in a JSDoc comment shouldn't be allow-listed in the gate-coverage test, because that creates a permanent blind spot — any future real driveMembers query in that file would silently pass CI without an isNotNull gate. Strip block comments and line comments from the source before applying the DRIVE_MEMBERS_REFERENCE regex. Removes the invite-acceptance.ts allow-list entry since the docstring is now ignored. Future real reads in any lib file still get scanned and gated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 of 8 tasks
Owner
Author
|
Superseded by #1267. Same architecture, cleaner scope and history. Closing this PR. |
2witstudios
added a commit
that referenced
this pull request
May 7, 2026
* docs(invites): GDPR zero-trust epic spec Restart of #1266. New epic file scoped to the approved plan: hard-cutover deletions of post-login broad-sweep + 9 auth callers + resend route, magic-link service body untouched, wipe-not-port migration, /invite/[token]/accept gateway as its own task. Supersedes #1266. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): scaffold pending_invites table Add pending_invites schema with token_hash, email, drive_id, role, invited_by, expires_at, consumed_at. Both FKs cascade on delete. Partial unique index on (drive_id, email) WHERE consumed_at IS NULL prevents duplicate active invites at the DB level. Wired into schema barrel + namespace + package exports. Migration 0122 generated via pnpm db:generate. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): add pure invite predicates isInviteExpired, isInviteConsumed, isEmailMatchingInvite — pure functions with destructured object args, now injected. Email match is case + whitespace insensitive (matches the trim+lowercase normalization the invite endpoint already applies). 15 colocated tests cover the boundary case (now equals expiresAt → expired) plus 1ms-before / 1ms-after. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): add invite token primitive createInviteToken({ now, expiryMinutes? }) mints ps_invite_* tokens with default 48h expiry. verifyInviteToken({ token, tokenHash }) compares via secureCompare (timing-safe). Reuses generateToken + hashToken from token-utils — no new hashing primitive. 9 colocated tests cover expiry math, prefix shape, hash distinctness, mint-twice uniqueness, and rejection of empty/tampered tokens. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): pendingInvites repository CRUD Add createPendingInvite (sweeps expired-unconsumed for the (driveId, email) pair before insert so the partial unique index never blocks legit re-invites), findPendingInviteByTokenHash (joined drive name + inviter name), findActivePendingInviteByDriveAndEmail (filters consumedAt IS NULL AND expiresAt > now), markInviteConsumed (atomic conditional UPDATE), deletePendingInvite, findUserToSStatusByEmail, and consumeInviteAndCreateMembership — a single Drizzle transaction that conditionally consumes the token then inserts driveMembers; throws a sentinel on (driveId, userId) unique violation so the transaction rolls back and the caller receives ALREADY_MEMBER without burning the token. 15 new tests cover happy/race/duplicate/connection-error paths. Legacy methods (findPendingMembersForUser, acceptPendingMember, bumpInvitedAt) remain in place; T9 deletes them once their callers are removed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): rewrite invite endpoint handleEmailPath swaps createMagicLinkToken + createDriveMember(acceptedAt:null) for createInviteToken + createPendingInvite. URL becomes /invite/<rawToken>. Active-pending pre-check uses findActivePendingInviteByDriveAndEmail. Concurrent re-invite race surfaces as 409 via partial unique index. Email-send failure rolls back via deletePendingInvite. logMemberActivity is intentionally not called on the pending path — there is no targetUserId, the audit event captures the email-keyed invite. handleUserIdPath is unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): /invite/[token] consent page resolveInviteContext({ token, now }) hashes the token (SHA3, never plaintext) and returns a discriminated result: data with drive name, inviter name, role, invited email, and isExistingUser (tosAcceptedAt IS NOT NULL); or NOT_FOUND/EXPIRED/CONSUMED. The server-component page awaits Next.js 15 async params and renders the consent card with ToS/Privacy CTAs — or an opaque 'no longer valid' card on any failure (NEVER redirects, which would leak token existence). 7 colocated resolver tests cover the happy paths + each error variant + the SHA-not-plaintext lookup contract. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): /invite/[token]/accept gateway acceptInviteForExistingUser + acceptInviteForNewUser pipes share validateAndLoadInvite + consumeAndShape so the discriminated TOKEN_NOT_FOUND/EXPIRED/CONSUMED/EMAIL_MISMATCH/ALREADY_MEMBER ladder is identical across signup and existing-user paths. The existing-user path runs findExistingMember pre-check so already-accepted users surface ALREADY_MEMBER without burning the token. The GET handler authenticates via session, redirects unauth'd users to /auth/signin?invite=&next=, redirects success to /dashboard/<driveId>?invited=1, redirects failure to /dashboard?inviteError=<code>. 12 pipe tests + 5 gateway tests. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(auth): wire ?invite= into signup flow + ToS checkbox Server signup page resolves ?invite= via resolveInviteContext and passes invite context + token to a new SignUpClient (extracted from CloudSignUp). PasskeySignupButton replaces the hardcoded acceptedTos:true with a real checkbox above submit, accepts a lockedEmail prop (disabled+prefilled email), and forwards inviteToken in the POST body. signup-passkey/route.ts accepts an optional inviteToken in zod and runs acceptInviteForNewUser after session creation NON-FATALLY — signup still succeeds; the dashboard surfaces ?inviteError=<code>. A successful invite acceptance overrides the getting-started provisioning redirect to /dashboard/<driveId>?welcome=true. The duplicate 'By signing up...' footer paragraph is removed (the checkbox replaces it). 4 new tests for the inviteToken plumbing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(invites): hard-cutover deletions Delete the broad-sweep acceptUserPendingInvitations helper, its 9 auth-route call-sites (apple/native, apple/callback, magic-link/verify, passkey/authenticate, google/native, google/one-tap, google/callback, signup-passkey, mobile/oauth/google/exchange), the post-login-acceptance-coverage gate test, and the now-orphan findPendingMembersForUser/acceptPendingMember/bumpInvitedAt repo methods. Delete the resend route + its tests + handleResendInvitation/onResend plumbing in DriveMembers/MemberRow. Remove the orphaned INVITATION_LINK_EXPIRY_MINUTES constant from magic-link-service.ts (its body is otherwise untouched). The magic-link verify route's matchedInviteDriveId hint is also gone — drive-invite acceptance now lives entirely on the new pendingInvites flow. No no-op shims, no dead UI gated by always-false flags, no orphaned routes — per feedback_no_backwards_compat_for_unreleased.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(db): one-shot pending_invites data migration migrate-pending-invites: idempotent transactional script that wipes legacy drive_members rows where acceptedAt IS NULL plus the orphan email-only users they reference (provider='email' AND tosAcceptedAt IS NULL AND emailVerified IS NULL AND no passkeys AND no remaining drive_members). The original raw invite token was never persisted, so the legacy rows cannot be ported into pending_invites; the script emits the (driveId, email) pairs to stdout instead so admins can re-invite via the new flow. Run BEFORE deploying the new code. --dry-run flag prints the wipe set without mutating. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(invites): unblock collapsed CTA + classify by account presence P0 (CodeRabbit): PasskeySignupButton's collapsed 'Create with Passkey' trigger was disabled by !acceptedTos, but the ToS checkbox only renders inside the expanded form — making signup unreachable for everyone. Split the gate: collapsed expand-trigger requires only the base disabled state, the in-form submit button additionally requires acceptedTos. P1 (CodeRabbit): isExistingUser was gated on tosAcceptedAt != null, which misroutes OAuth/magic-link users (and accounts predating the ToS column) to /auth/signup where signup-passkey returns EMAIL_EXISTS — invites become unclaimable. Gate on account presence (tosStatus !== null) instead; the accept gateway handles ToS re-prompting separately. Allow-list invite-acceptance.ts in the lib drive-member gate sweep — the lone driveMembers reference is documentation prose, the actual write goes through the already-allow-listed repository seam. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(invites): drop redundant idx, document UI scope, gate suspended CodeRabbit nits + defense-in-depth: - Drop redundant explicit B-tree index on pending_invites.token_hash — the UNIQUE constraint already creates an implicit index. Migration regenerated as 0122_easy_carlie_cooper.sql; net change is 1 fewer CREATE INDEX statement and saved write overhead. - Document the intentionally-empty pendingMembers section in DriveMembers.tsx — pending state lives in pending_invites and surfacing it through the members API is explicit follow-up scope (epic 'Out of scope'). The legacy filter remains as a safety net for any straggler acceptedAt=null row that might survive cutover. - Defense-in-depth: explicitly reject suspended sessions in /invite/[token]/accept (suspended users are already rejected at the session layer, but reading suspendedAt here makes the gate survive any future refactor of the auth helpers). New test asserts ACCOUNT_SUSPENDED redirect + no consume. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2witstudios
added a commit
that referenced
this pull request
May 15, 2026
* docs(invites): GDPR zero-trust epic spec Restart of #1266. New epic file scoped to the approved plan: hard-cutover deletions of post-login broad-sweep + 9 auth callers + resend route, magic-link service body untouched, wipe-not-port migration, /invite/[token]/accept gateway as its own task. Supersedes #1266. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): scaffold pending_invites table Add pending_invites schema with token_hash, email, drive_id, role, invited_by, expires_at, consumed_at. Both FKs cascade on delete. Partial unique index on (drive_id, email) WHERE consumed_at IS NULL prevents duplicate active invites at the DB level. Wired into schema barrel + namespace + package exports. Migration 0122 generated via pnpm db:generate. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): add pure invite predicates isInviteExpired, isInviteConsumed, isEmailMatchingInvite — pure functions with destructured object args, now injected. Email match is case + whitespace insensitive (matches the trim+lowercase normalization the invite endpoint already applies). 15 colocated tests cover the boundary case (now equals expiresAt → expired) plus 1ms-before / 1ms-after. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): add invite token primitive createInviteToken({ now, expiryMinutes? }) mints ps_invite_* tokens with default 48h expiry. verifyInviteToken({ token, tokenHash }) compares via secureCompare (timing-safe). Reuses generateToken + hashToken from token-utils — no new hashing primitive. 9 colocated tests cover expiry math, prefix shape, hash distinctness, mint-twice uniqueness, and rejection of empty/tampered tokens. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): pendingInvites repository CRUD Add createPendingInvite (sweeps expired-unconsumed for the (driveId, email) pair before insert so the partial unique index never blocks legit re-invites), findPendingInviteByTokenHash (joined drive name + inviter name), findActivePendingInviteByDriveAndEmail (filters consumedAt IS NULL AND expiresAt > now), markInviteConsumed (atomic conditional UPDATE), deletePendingInvite, findUserToSStatusByEmail, and consumeInviteAndCreateMembership — a single Drizzle transaction that conditionally consumes the token then inserts driveMembers; throws a sentinel on (driveId, userId) unique violation so the transaction rolls back and the caller receives ALREADY_MEMBER without burning the token. 15 new tests cover happy/race/duplicate/connection-error paths. Legacy methods (findPendingMembersForUser, acceptPendingMember, bumpInvitedAt) remain in place; T9 deletes them once their callers are removed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): rewrite invite endpoint handleEmailPath swaps createMagicLinkToken + createDriveMember(acceptedAt:null) for createInviteToken + createPendingInvite. URL becomes /invite/<rawToken>. Active-pending pre-check uses findActivePendingInviteByDriveAndEmail. Concurrent re-invite race surfaces as 409 via partial unique index. Email-send failure rolls back via deletePendingInvite. logMemberActivity is intentionally not called on the pending path — there is no targetUserId, the audit event captures the email-keyed invite. handleUserIdPath is unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): /invite/[token] consent page resolveInviteContext({ token, now }) hashes the token (SHA3, never plaintext) and returns a discriminated result: data with drive name, inviter name, role, invited email, and isExistingUser (tosAcceptedAt IS NOT NULL); or NOT_FOUND/EXPIRED/CONSUMED. The server-component page awaits Next.js 15 async params and renders the consent card with ToS/Privacy CTAs — or an opaque 'no longer valid' card on any failure (NEVER redirects, which would leak token existence). 7 colocated resolver tests cover the happy paths + each error variant + the SHA-not-plaintext lookup contract. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(invites): /invite/[token]/accept gateway acceptInviteForExistingUser + acceptInviteForNewUser pipes share validateAndLoadInvite + consumeAndShape so the discriminated TOKEN_NOT_FOUND/EXPIRED/CONSUMED/EMAIL_MISMATCH/ALREADY_MEMBER ladder is identical across signup and existing-user paths. The existing-user path runs findExistingMember pre-check so already-accepted users surface ALREADY_MEMBER without burning the token. The GET handler authenticates via session, redirects unauth'd users to /auth/signin?invite=&next=, redirects success to /dashboard/<driveId>?invited=1, redirects failure to /dashboard?inviteError=<code>. 12 pipe tests + 5 gateway tests. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(auth): wire ?invite= into signup flow + ToS checkbox Server signup page resolves ?invite= via resolveInviteContext and passes invite context + token to a new SignUpClient (extracted from CloudSignUp). PasskeySignupButton replaces the hardcoded acceptedTos:true with a real checkbox above submit, accepts a lockedEmail prop (disabled+prefilled email), and forwards inviteToken in the POST body. signup-passkey/route.ts accepts an optional inviteToken in zod and runs acceptInviteForNewUser after session creation NON-FATALLY — signup still succeeds; the dashboard surfaces ?inviteError=<code>. A successful invite acceptance overrides the getting-started provisioning redirect to /dashboard/<driveId>?welcome=true. The duplicate 'By signing up...' footer paragraph is removed (the checkbox replaces it). 4 new tests for the inviteToken plumbing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(invites): hard-cutover deletions Delete the broad-sweep acceptUserPendingInvitations helper, its 9 auth-route call-sites (apple/native, apple/callback, magic-link/verify, passkey/authenticate, google/native, google/one-tap, google/callback, signup-passkey, mobile/oauth/google/exchange), the post-login-acceptance-coverage gate test, and the now-orphan findPendingMembersForUser/acceptPendingMember/bumpInvitedAt repo methods. Delete the resend route + its tests + handleResendInvitation/onResend plumbing in DriveMembers/MemberRow. Remove the orphaned INVITATION_LINK_EXPIRY_MINUTES constant from magic-link-service.ts (its body is otherwise untouched). The magic-link verify route's matchedInviteDriveId hint is also gone — drive-invite acceptance now lives entirely on the new pendingInvites flow. No no-op shims, no dead UI gated by always-false flags, no orphaned routes — per feedback_no_backwards_compat_for_unreleased.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(db): one-shot pending_invites data migration migrate-pending-invites: idempotent transactional script that wipes legacy drive_members rows where acceptedAt IS NULL plus the orphan email-only users they reference (provider='email' AND tosAcceptedAt IS NULL AND emailVerified IS NULL AND no passkeys AND no remaining drive_members). The original raw invite token was never persisted, so the legacy rows cannot be ported into pending_invites; the script emits the (driveId, email) pairs to stdout instead so admins can re-invite via the new flow. Run BEFORE deploying the new code. --dry-run flag prints the wipe set without mutating. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(invites): unblock collapsed CTA + classify by account presence P0 (CodeRabbit): PasskeySignupButton's collapsed 'Create with Passkey' trigger was disabled by !acceptedTos, but the ToS checkbox only renders inside the expanded form — making signup unreachable for everyone. Split the gate: collapsed expand-trigger requires only the base disabled state, the in-form submit button additionally requires acceptedTos. P1 (CodeRabbit): isExistingUser was gated on tosAcceptedAt != null, which misroutes OAuth/magic-link users (and accounts predating the ToS column) to /auth/signup where signup-passkey returns EMAIL_EXISTS — invites become unclaimable. Gate on account presence (tosStatus !== null) instead; the accept gateway handles ToS re-prompting separately. Allow-list invite-acceptance.ts in the lib drive-member gate sweep — the lone driveMembers reference is documentation prose, the actual write goes through the already-allow-listed repository seam. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(invites): drop redundant idx, document UI scope, gate suspended CodeRabbit nits + defense-in-depth: - Drop redundant explicit B-tree index on pending_invites.token_hash — the UNIQUE constraint already creates an implicit index. Migration regenerated as 0122_easy_carlie_cooper.sql; net change is 1 fewer CREATE INDEX statement and saved write overhead. - Document the intentionally-empty pendingMembers section in DriveMembers.tsx — pending state lives in pending_invites and surfacing it through the members API is explicit follow-up scope (epic 'Out of scope'). The legacy filter remains as a safety net for any straggler acceptedAt=null row that might survive cutover. - Defense-in-depth: explicitly reject suspended sessions in /invite/[token]/accept (suspended users are already rejected at the session layer, but reading suspendedAt here makes the gate survive any future refactor of the auth helpers). New test asserts ACCOUNT_SUSPENDED redirect + no consume. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Stops creating
usersrows at invite-send time. Drive invites now flow through a dedicatedpending_invitestable with zero-auth-power tokens, a server-rendered consent screen, and an explicit ToS checkbox at signup. New users hit/auth/signup?invite=<token>(locked email, banner, real ToS gate); existing users come through/invite/[token]/accept(session-gated, no magic-link bypass). EverydriveMembersrow after this PR represents real, accepted membership — theacceptedAt IS NULLsemantic is gone.Closes the GDPR Art. 6 + Art. 13 exposure (no PII processed before affirmative consent), removes the 7-day forwardable account-takeover credential, and stops silently bypassing passkeys for users who configured one.
Plan:
tasks/drive-invite-gdpr-zero-trust.md. 12 atomic TDD-gated subtasks.What changed
pending_invitestable (tokenHash, email, driveId, role, invitedBy, expiresAt, consumedAt) with a partial unique index on(driveId, email) WHERE consumedAt IS NULL. Migration0122_early_morlun.sql.isInviteExpired,isInviteConsumed,isEmailMatchingInvitepredicates;createInviteToken/verifyInviteTokenreusing the existing SHA3-256 + timing-safe-compare primitives.createPendingInvite,findPendingInviteByTokenHash(single joined query for drive+inviter context),markInviteConsumed,findActivePendingInviteByDriveAndEmail(filtersexpiresAt > nowso expired-unconsumed rows can't 409 indefinitely),deletePendingInvite,findUserToSStatusByEmail, andconsumeInviteAndCreateMembership(transactional consume+insert with optional legacy-row cleanup). RemovedfindPendingMembersForUserandfindActivePendingMemberByEmail./api/drives/[driveId]/members/inviteno longer issues magic-link tokens or auto-creates ausersrow. Verified-existing-user fast path is unchanged. Default invite expiry shortens from 7 days to 48h./invite/[token]/page.tsxserver component renders inviter + drive + role + invited email + ToS/Privacy links. Invalid/expired/consumed tokens render an opaque card; never redirect (would leak token existence)./auth/signupis now server-rendered with?invite=resolved server-side; banner + locked email; PasskeySignupButton has a real ToS checkbox replacing the hardcodedacceptedTos: true. After signup,acceptInviteForNewUserconsumes the invite via the transactional repo helper and redirects to the joined drive (or surfaces a non-blocking dashboard toast on stale-invite)./invite/[token]/acceptGET handler is the single chokepoint for existing-user acceptance: requires session viaauthenticateRequestWithOptions; redirects unauthenticated users to/auth/signin?invite=<token>&next=...; runsacceptInviteForExistingUserpost-auth. Decouples the pipe from the 9 separate auth methods. Cleans up legacy pendingdrive_membersrows inside the same transaction so the unique(driveId, userId)constraint cannot fire during the deploy window.createMagicLinkTokenreturnsNO_ACCOUNT_FOUNDfor unknown emails; the existing enumeration-safe response in/api/auth/magic-link/sendhandles it without leaking.isNewUseris gone from the result types.acceptUserPendingInvitationsis downgraded to a deprecated no-op shim. Function name + signature preserved so thepost-login-acceptance-coveragegate keeps firing and the 9 callers continue to compile, but the broad userId-keyed query is deleted.pnpm --filter @pagespace/db migrate-pending-invitesis a clean wipe rather than an in-place port (the original raw token was never persisted, so a migrated row would be unusable AND would 409-block admins from re-inviting). It deletes legacy pendingdrive_membersrows and orphan users (no auth credentials), and emits the(drive, email)pairs admins should re-invite through the normal flow. Idempotent.Eric Elliott style
Pure predicates with destructured object args,
nowinjected. Composed acceptance pipes return discriminated{ ok, data | error }results — no exceptions across boundaries. Tests follow the 5-question discipline (describenames the unit, everyitcarries the situation+expectation, every assertion pairs explicit actual vs expected).Notable decisions / deviations
generateToken('ps_invite')convention used for sessions, magic-links, MCP tokens. The plan said "32 bytes base64url" but reusing the codebase's pattern was the higher-value adherence.acceptUserPendingInvitationskept as no-op shim rather than fully deleted across all 9 routes. Pragmatic call: the broad-sweep query is gone (no vulnerability surface), the coverage gate continues to enforce the contract, and the 9 routes don't churn. Final removal pairs with the production data-migration validation.logMemberActivityskipped on the pending-invite path — itstargetUserIdis required (used as the activity-log resource id), and there's no users row at invite-send time.auditRequestcaptures the event keyed on email instead./api/drives/[driveId]/members/[userId]/resendand theMemberRow.tsx"Resend" button are scoped ondriveMemberskeyed by userId; that surface is moot post-cutover (pending state lives inpending_inviteskeyed by email). The route still works for legacy data during the deploy window. A focused follow-up will surfacepending_invitesrows in the members UI and rewrite resend against email-keyed pending invites.next=redirect after sign-in for existing-user invitees —/invite/[token]/acceptredirects unauthenticated users to/auth/signin?invite=<token>&next=/invite/<token>/accept, but the signin page's auth methods don't yet honornext=. Today: existing user signs in, lands at/dashboard, re-clicks the invite email, and the now-authenticated/acceptroute runs the pipe. Two-click flow until a follow-up addsnext=plumbing across passkey/magic-link/OAuth callbacks.Atomicity guarantees
UPDATE pending_invites SET consumedAt=now() WHERE id=X AND consumedAt IS NULL RETURNING id— concurrent acceptance attempts cannot both succeed.consumeInviteAndCreateMembership. The pending_invites consume, the optional legacydrive_membersdeletion, and the fresh accepted-membership insert all run in a single Drizzle transaction. If any step fails, the consume is rolled back so the user can retry.pending_invitesrow so a transient SMTP failure can't leave an orphan that 409-blocks subsequent invites.Test plan
pnpm --filter web typecheckcleanpnpm --filter @pagespace/lib typecheckcleanpnpm --filter @pagespace/db typecheckcleanpnpm --filter web lint,@pagespace/lib lint,@pagespace/db lintclean (one pre-existing warning inQuickCreatePalette.tsxunrelated to this PR)pnpm --filter web dev:next=deviation note)pnpm --filter @pagespace/db migrate-pending-invitesagainst dev DB and confirm idempotenceOut of scope (follow-ups)
pending_invitesrows.next=redirect plumbing across all auth methods so existing-user invitees can sign in once and land directly in the drive.🤖 Generated with Claude Code