Move Chambers from Supabase to Neon (#136) - #143
Merged
Merged
Conversation
- db/neon/0001_baseline.sql: production public schema from the live catalog, FKs to auth.users repointed at public.users, no RLS policies or Supabase helper functions, RLS left enabled as default deny. - db/neon/0002_better_auth.sql: Better Auth mapped onto public.users, plus auth_sessions, auth_accounts and auth_verifications. - scripts/neon/copy-data.mjs: copies every table in FK order in one transaction, imports Supabase logins with their bcrypt hashes, verifies row counts. - lib/better-auth.ts, lib/auth-client.ts, lib/auth-admin.ts and /api/auth/[...all]: Better Auth with bcrypt passwords, sign-up disabled, password reset through Resend, deactivated users refused a session. - lib/auth.ts, lib/authorization.ts, lib/shell-identity.ts read the Better Auth session and the users row through a pg pool. - Client pages read roles from the shell identity instead of token metadata. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Login flows now run on Better Auth: sign-in, password reset (through Resend), the signup code, onboarding, admin invites and resends, deactivation and session revocation. The browser no longer queries the database -- the login and onboarding pages ask three new API routes instead -- and roles are read from the users row rather than copied into a token. Sessions last two days of inactivity, extended at most hourly while in use, matching the dashboard's existing idle sign-out. Row-level security is no longer part of access control (decided on #136). Supabase cannot identify a Better Auth user, so the server clients use the service role, and every route relies on the checks it already made in application code before querying. The Neon schema keeps RLS enabled with no policies, so anything other than the app's own role is denied by default. Also: proxy.ts and the browser Supabase client are gone, AuthedUser moved to lib/auth-types.ts so browser-shared modules do not import server code, the warm cron warms the Postgres pool, and .env.example documents DATABASE_URL, BETTER_AUTH_SECRET and BETTER_AUTH_URL. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…y-schema script (#136) The login import passed one parameter as both the uuid user_id and the text account_id, which Postgres refuses. apply-schema.mjs applies db/neon/*.sql to an empty database in one transaction. Rehearsed against the new Neon project: schema applied (34 tables), dry run and real copy both passed with every row count matching and 37 logins imported. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…136) The Data API switches to the Postgres role named in the request token. The server will sign short-lived tokens as chambers_server with a private key only it holds; public/data-api-jwks.json is the matching public key for Neon to verify them. chambers_server gets full access to the app tables through one permissive policy each, and none to the auth_* tables. Adds jose and @supabase/postgrest-js as direct dependencies. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…#136) Rehearsed on a Neon branch: nested selects, a nested-table filter, aliased FK embeds, .or(), head counts, single(), and a restored write all work through the Data API with a server-signed chambers_server token. Requests with no token or an ordinary authenticated token get nothing, and the auth_* tables stay closed. after-data-api.sql grants chambers_server to authenticator, which only exists once the Data API is enabled. The runbook now covers enabling it, registering the key, and refreshing the schema cache, which Neon does not do on its own after DDL. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… app (#136) Every Supabase client -- the 54 service-role admin clients, the 53 routes using lib/supabase/server, the homepage's anon client and the FAQ page -- is now lib/db/data-api.ts: a PostgREST client pointed at the Neon Data API that signs its own ten-minute chambers_server token per request. The queries themselves are unchanged; the Data API speaks the same protocol. @supabase/supabase-js and @supabase/ssr are uninstalled, lib/supabase and the realtime-js stub (and its bundler alias) are deleted. next.config gains an empty turbopack block, which Next 16 requires beside next-pwa's webpack config once no other turbopack option is set. Checked: typecheck, production build (whose prerender queries Neon), and the homepage and FAQ reading live data from the rehearsal branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… a database (#136) - scripts/neon/cutover.mjs loads a Neon branch from Supabase in one command: refuses unless --target-endpoint matches the URL and the Data API is enabled, drops existing tables only with --reset-target, then applies the schema, copies data and logins, and grants the Data API role. --check reports the plan without writing. - scripts/neon/compare-counts.mjs, run after the deploy, lists tables with rows Supabase gained after the copy. - public/data-api-jwks-production.json holds only the production key, so production's Data API never trusts the dev and rehearsal key. - The database client reports a missing NEON_DATA_API_URL as a query error instead of throwing on first use, the FAQ falls back to role titles, and Better Auth gets a placeholder secret during next build only. Together these let CI build with no database or auth configuration; CI no longer passes the Supabase secrets. - Runbook and .env.example updated for the Data API and the Sept 19 cutover. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pataniaeli
added
enhancement
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
) scripts/neon/generate-baseline.mjs rebuilds db/neon/0001_baseline.sql from Supabase's live catalog, read-only, with the same rules as the hand-built version: auth.users foreign keys repointed at public.users, no policies or Supabase helper functions, RLS enabled as default deny. Regenerated today to pick up the migrations that reached production since Sept 17: audit_logs target/target_date/action/changes and their checks, the Dismissed cancellation status, and audit_logs_booking_created_idx. Nothing else differs from the previous hand-built file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Merged
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.
Closes #136
Moves Chambers' database and login off Supabase. Target cutover: September 19. Plan and status: https://claude.ai/artifact/PHfVdZYHYDvja9dats7j4o
What changes
public.users, so ids are unchanged. Supabase's bcrypt hashes are imported and verified with bcrypt, so nobody resets a password. This was proven by signing in with a real password on the rehearsal branch. Public sign-up is off: accounts come only from invites and the signup-code flow (lib/auth-admin.ts). Password reset emails go through Resend. A deactivated account can't start a session.lib/db/data-api.tsreplaces every Supabase client (54 service-role clients, 53createClient()routes, the homepage and FAQ clients). The server signs a ten-minute token aschambers_server, a role with full access to app tables and none toauth_*.chambers_server's, so any other role sees nothing.@supabase/supabase-js,@supabase/ssr,lib/supabase/,proxy.ts, and the realtime-js stub.Tested on the rehearsal branch (production untouched)
.or(), counts and a write. Requests with no token, or an ordinary user's token, are refused.next buildpasses, including with no database or auth variables, as in CI.Schema and scripts:
db/neon/,scripts/neon/0001_baseline.sql: the production schema, generated from the live catalog, with foreign keys toauth.usersrepointed atusers0002_better_auth.sql: Better Auth's tables0003_data_api_server_role.sql: thechambers_serverroleafter-data-api.sql: run on each branch once its Data API is enabledcutover.mjs: one command with guards (endpoint must match, Data API must be enabled, wipes only with--reset-target)copy-data.mjs: one transaction, every row count checkedcompare-counts.mjs: finds rows written to Supabase after the copytest-data-api.mjsdb/neon/README.mdVercel variables (Production)
Set these before merging to
main. The generated secrets are handed over separately, not in this PR.DATABASE_URLNEON_DATA_API_URLDATA_API_PRIVATE_JWKBETTER_AUTH_SECRETBETTER_AUTH_URLhttps://chambers.northeasternsga.comRemove after cutover:
NEXT_PUBLIC_SUPABASE_URL,NEXT_PUBLIC_SUPABASE_ANON_KEY,SUPABASE_SERVICE_ROLE_KEY. Nothing in the app reads them any more.Things to know
data-api-jwks-production.json, which holds only the production key.RESEND_API_KEYcrashes every route, sign-in included, because the Resend client throws at startup. That was always true, but login now loads it too. Production has the key. Hardening this is a follow-up.🤖 Generated with Claude Code