fix(invite): switch to verifyOtp + /auth/confirm — invite mails use hash-flow, not PKCE#129
Merged
Conversation
…-flow tokens, not PKCE codes The /auth/callback hop added in #127 only works for PKCE OAuth flows where the browser holds the code verifier. Admin-initiated invite emails (supabase.auth.admin.inviteUserByEmail) have no PKCE verifier on the recipient's browser — Supabase's verify endpoint returns the session as URL hash params (#access_token=...&refresh_token=...) which server components can't read. /auth/callback sees no ?code=, redirects to /sign-in?error=auth_callback_failed, and the user falls into the old broken /sign-up dance again. Canonical fix is the OTP-token-hash flow Supabase documents for SSR: - New /auth/confirm route handler reads ?token_hash + ?type + ?redirect_to, calls supabase.auth.verifyOtp({ type, token_hash }), and 302s to the destination once the session cookie is set server-side. Works for every Supabase email type (invite, signup, recovery, magiclink, email_change) — the type comes from the template, not from us. - team.ts inviteLink is now plain ${appUrl}/invite/<token> again. The auth hop is no longer in the redirect; it's in the email template's link itself. Required ops step (manual, not in code): the Supabase project's Auth → Email Templates → 'Invite user' template needs the link changed from {{ .ConfirmationURL }} to: {{ .SiteURL }}/auth/confirm?token_hash={{ .TokenHash }}&type=invite&redirect_to={{ .RedirectTo }} Same swap recommended for signup / recovery / magiclink templates so every email auth flow goes through the same SSR-friendly path. Until that's done the invite link still hits the old default URL and the fix doesn't take effect.
…template covers dev + prod
Previous attempt put /auth/confirm under {{ .SiteURL }} in the email
template. Supabase's Site URL is one project-wide value (production
https://app.ansvisor.com here), so the same template can't drive
both prod testing and a localhost dev loop — the link always points
at prod regardless of NEXT_PUBLIC_APP_URL.
Switch the redirectTo we pass to inviteUserByEmail to be the full
/auth/confirm URL with our next path baked in:
${appUrl}/auth/confirm?next=/invite/<token>
Template now uses {{ .RedirectTo }} as the prefix and only appends
the OTP params:
{{ .RedirectTo }}&token_hash={{ .TokenHash }}&type=invite
Because appUrl resolves to whichever NEXT_PUBLIC_APP_URL is in the
current environment, the link goes to localhost in dev and prod in
prod — without changing Supabase project settings between the two.
gkhngyk
added a commit
that referenced
this pull request
May 30, 2026
…ntl rewrite was 404ing (#130) * fix(invite): use verifyOtp via /auth/confirm — invite mails ship hash-flow tokens, not PKCE codes The /auth/callback hop added in #127 only works for PKCE OAuth flows where the browser holds the code verifier. Admin-initiated invite emails (supabase.auth.admin.inviteUserByEmail) have no PKCE verifier on the recipient's browser — Supabase's verify endpoint returns the session as URL hash params (#access_token=...&refresh_token=...) which server components can't read. /auth/callback sees no ?code=, redirects to /sign-in?error=auth_callback_failed, and the user falls into the old broken /sign-up dance again. Canonical fix is the OTP-token-hash flow Supabase documents for SSR: - New /auth/confirm route handler reads ?token_hash + ?type + ?redirect_to, calls supabase.auth.verifyOtp({ type, token_hash }), and 302s to the destination once the session cookie is set server-side. Works for every Supabase email type (invite, signup, recovery, magiclink, email_change) — the type comes from the template, not from us. - team.ts inviteLink is now plain ${appUrl}/invite/<token> again. The auth hop is no longer in the redirect; it's in the email template's link itself. Required ops step (manual, not in code): the Supabase project's Auth → Email Templates → 'Invite user' template needs the link changed from {{ .ConfirmationURL }} to: {{ .SiteURL }}/auth/confirm?token_hash={{ .TokenHash }}&type=invite&redirect_to={{ .RedirectTo }} Same swap recommended for signup / recovery / magiclink templates so every email auth flow goes through the same SSR-friendly path. Until that's done the invite link still hits the old default URL and the fix doesn't take effect. * fix(invite): use {{ .RedirectTo }}-based template prefix so a single template covers dev + prod Previous attempt put /auth/confirm under {{ .SiteURL }} in the email template. Supabase's Site URL is one project-wide value (production https://app.ansvisor.com here), so the same template can't drive both prod testing and a localhost dev loop — the link always points at prod regardless of NEXT_PUBLIC_APP_URL. Switch the redirectTo we pass to inviteUserByEmail to be the full /auth/confirm URL with our next path baked in: ${appUrl}/auth/confirm?next=/invite/<token> Template now uses {{ .RedirectTo }} as the prefix and only appends the OTP params: {{ .RedirectTo }}&token_hash={{ .TokenHash }}&type=invite Because appUrl resolves to whichever NEXT_PUBLIC_APP_URL is in the current environment, the link goes to localhost in dev and prod in prod — without changing Supabase project settings between the two. * fix(invite): mirror /auth/confirm under [locale]/(marketing) so next-intl can resolve it PR #129 added /auth/confirm at the root app directory only. next-intl middleware rewrites every /auth/* request to /[locale]/auth/*, and the deployed bundle had no matching file under [locale]/auth/confirm — so the request landed on the framework 404 page. The existing /auth/callback works because there's already a [locale]/(marketing)/auth/callback/route.ts that the rewrite resolves to. Add the equivalent mirror for confirm so the same routing rules have a destination. Verified via response headers — /auth/callback shows `x-matched-path: /[locale]/auth/callback`, /auth/confirm before this change matched /404 with x-vercel-cache HIT. Keeping the root /auth/confirm/route.ts around to stay consistent with the callback sibling pattern; it's never hit but matches the existing convention.
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
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.
What
#127 routed invite-mail clicks through
/auth/callbackon the assumption that Supabase appends a PKCE?code=to the redirect URL. It doesn't — for admin-initiated invites, the recipient's browser never held a PKCE verifier, so Supabase's verify endpoint returns the session as URL hash params (#access_token=...&refresh_token=...). Server components can't see the hash,/auth/callbacksaw no?code=, redirected to/sign-in?error=auth_callback_failed, and the user fell into the same old broken/sign-uploop.Why
This is the canonical "server-side auth with Supabase + Next.js" gotcha. Anthropic / Vercel / Supabase docs all converge on the same answer: don't use
{{ .ConfirmationURL }}, use{{ .TokenHash }}+ a custom/auth/confirmroute that callsverifyOtpserver-side.Scope
/auth/confirmroute handler. Reads?token_hash,?type,?redirect_to(or?next), callssupabase.auth.verifyOtp({ type, token_hash }), and 302s to the destination once the cookie session is set server-side. Handles every Supabase email type — invite, signup, recovery, magiclink, email_change.team.tsreverts the/auth/callback?next=...hop.inviteLinkis now plain${appUrl}/invite/<token>. The auth verification happens inside the email-template URL, not as a separate intermediate redirect.Required ops step (NOT in code)
The Supabase project's email templates need updating in Auth → Email Templates. Change the link href in the Invite user template from
{{ .ConfirmationURL }}to:Recommended to do the same on the Confirm signup, Reset password, and Magic link templates (
type=signup/recovery/magiclink) so every auth email goes through the same SSR-friendly path.Until the template is updated, the invite link in the email still goes to the old Supabase verify endpoint and this fix has no effect.
Test plan
auth.users/invitationsfor the test email/invite/<token>directly, signed in, with the AcceptInvitationCard ready/dashboardOut of scope
/auth/callbackstays as-is — it's still the correct route for any future PKCE OAuth flows (Google / GitHub sign-in if added).auth.userscleanup gap — separate fix.