Add the Dex-subject -> tapir-user_id bridge for multi-user Stage 1. Migration 004 creates user_identities (dex_subject PK, user_id UNIQUE FK ON DELETE CASCADE). It is intentionally NOT RLS-enabled: it holds no user data and must be readable BEFORE a user_id is known (the lookup is what yields the id used to set tapir.current_user_id). RLS here would be a chicken-and-egg deadlock; data isolation stays on the user-owned tables. UserBySubject resolves subject -> user_id as a plain pool query (pre-scope, no withUser). RegisterUser generates the UUID app-side (stdlib crypto/rand, no new dep) so the forced-RLS WITH CHECK (id = GUC) passes, then inserts the users row via withUser(newID) and the identity row in the same transaction. Re-registration of a subject errors with ErrSubjectRegistered. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2 lines
38 B
SQL
2 lines
38 B
SQL
DROP TABLE IF EXISTS user_identities;
|