Add Google sign-in
Configure Google through Supabase and implement the OAuth entry point missing from the tested starter's sign-in form.
Requires: Authority over the Google OAuth configuration and Supabase project, a working local callback route, local and production origins, and a separate email/password recovery sign-in.
Done when: “Continue with Google” creates a real session, profile, protected route access, and sign-out locally and in production.
Step 0 — Check the ground
At the tested commit, the oauth-providers.ts registry lists Google and the /auth/callback route can exchange an OAuth code, but auth-form.tsx executes email/password only and has no signInWithOAuth call. Treat the button as implementation work, not as an already working starter feature. These files were checked on 2026-07-25.
Prepare the change
- Read Supabase's Google login guide and the pinned starter's authentication guide.
- Record the intended Google account/project, consent-facing identity, application origins, Supabase provider callback shown in the dashboard, local and production app callbacks, and recovery route. Do not change either dashboard.
Context: Inspect the pinned auth form, Supabase browser client, provider
registry, callback route, profile trigger, sign-out route, and tests. Do not
change provider dashboards.
Plan the smallest Google sign-in implementation. Show exact files, UI/error
states, signInWithOAuth redirect construction, callback/session behavior, and
local plus production tests. Identify every external configuration step
separately and stop for human approval before editing or dashboard changes.Approval gate
The owner approves the Google project/account, consent-facing identity, origins, Supabase callback, Site URL, redirect allow-list, and production domain. A reviewer checks that the client secret is stored only in the provider dashboard and that the application redirect returns only to approved origins.
Steps
- In Google, configure the approved OAuth web client and add the exact Supabase provider callback shown by the dashboard.
- Store the Google client ID and secret in Supabase's Google provider configuration. Do not put the client secret in browser code or Git.
- In Supabase URL configuration, set the approved Site URL and exact local and production application callbacks, including
/auth/callback. Avoid a broad wildcard unless its risk is explicitly understood and approved. - Add a visible “Continue with Google” control to the sign-in experience.
- On activation, use the browser Supabase client to call
signInWithOAuthwith providergoogleand aredirectTobuilt from the current approved origin plus/auth/callback. - Preserve loading, cancellation, and useful error behavior. Keep email/password as a recovery route unless the PRD deliberately removes it.
- Test the complete local path: Google → Supabase → app callback → cookie session → profile trigger → protected
/app→ sign-out. - Repeat with the production origin after a separate production-configuration approval. Automated auth tests do not replace this real redirect test.
Verify
- The Google control is keyboard reachable and reports failure.
- A new Google user returns through
/auth/callback. - The session survives navigation/refresh and opens the protected route.
- The profile record is created as expected.
- Sign-out removes protected access.
- An unapproved redirect is rejected.
- Local and production are tested manually with no credential in Git/logs.
Save point
Commit the UI, handler, and tests without dashboard secrets. Record local and production verification separately in the milestone review.
If this fails
- Google reports redirect mismatch: compare the exact Supabase provider callback in Google; do not substitute the app callback.
- Supabase returns but the app rejects: check the app callback allow-list, origin, code exchange, and cookies.
- The profile is missing: inspect the applied trigger migration and callback logs without exposing tokens.
- Production loops to sign-in: verify production URL settings, environment values, cookies, and deployed commit.
- The Google setup cannot be completed live: use the tested email/password recovery path and schedule OAuth configuration outside the session.