fix(invite): mirror /auth/confirm under [locale]/(marketing) — next-intl rewrite was 404ing#130
Merged
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.
…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.
Closed
7 tasks
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.
What
PR #129 added the new
/auth/confirmroute at the app-root level only:After merge + deploy the route still returned 404. Diagnosed via response headers:
/auth/callback/[locale]/auth/callback/auth/confirm/404/en/auth/confirmnext-intl middleware rewrites
/auth/*to/[locale]/auth/*for every request./auth/callbackworks because there's already a[locale]/(marketing)/auth/callback/route.tsfor the rewrite to land on. We didn't have one for confirm.Scope
web/src/app/[locale]/(marketing)/auth/confirm/route.ts— sameverifyOtp({ type, token_hash })logic as the root sibling, just at the path next-intl actually resolves to./auth/confirmfile around to stay consistent with how the callback pair is shaped (root + locale, even though only locale is hit in practice).Test plan
curl -I https://app.ansvisor.com/auth/confirmshould now showx-matched-path: /[locale]/auth/confirmand a 302/307 (route runs, falls into the missing-params branch with no token_hash){{ .RedirectTo }}&token_hash={{ .TokenHash }}&type=invite/invite/<token>signed in → set password → join → sign back in