Skip to content

fix: full-page navigation after login so the session is applied (#365)#398

Merged
ArnasDon merged 1 commit into
mainfrom
fix/365-login-ngrok-redirect
Jul 17, 2026
Merged

fix: full-page navigation after login so the session is applied (#365)#398
ArnasDon merged 1 commit into
mainfrom
fix/365-login-ngrok-redirect

Conversation

@ArnasDon

Copy link
Copy Markdown
Owner

Summary

Over an ngrok tunnel, clicking Sign in just refreshed the login page instead of logging in — it worked fine on localhost.

Root cause

The login page signs in client-side, then does a soft navigation into a middleware-gated route:

await supabase.auth.signInWithPassword({ email, password });
router.push("/dashboard");

/dashboard is protected by src/middleware.ts, which redirects to /login unless supabase.auth.getUser() sees the session. A soft router.push can reach the protected route before the server-side layer reliably observes the just-written auth cookies, so the middleware bounces /dashboard → /login — and the page appears to "just refresh."

The repo already knows this pattern: the invite-accept flow in src/app/join/[token]/page.tsx deliberately uses a full reload ("not router.push, so AuthProvider re-fetches"). Login was the lone outlier still using the fragile soft navigation.

Why ngrok and not localhost: environmental. HTTPS + proxy latency widen the timing window, and on Next.js 16 cross-origin dev resources (HMR, the dev overlay) are blocked by default unless the tunnel host is allow-listed.

Changes

  • src/app/(auth)/login/page.tsx — navigate with window.location.href after signInWithPassword, mirroring the join flow so the next top-level request carries the fresh cookies to the middleware (removes the now-unused useRouter).
  • next.config.ts — add allowedDevOrigins for common dev tunnels (ngrok / cloudflared / localtunnel), extendable via ALLOWED_DEV_ORIGINS, so Next 16 stops returning 403 for dev-only resources over the tunnel.

Testing

  • tsc --noEmit
  • eslint (changed files) ✅
  • vitest run src/middleware.test.ts ✅ (4/4)

A full login-over-ngrok reproduction needs a live Supabase project + an active tunnel, which isn't available in the dev sandbox; the fix rests on the middleware logic, the passing checks, and consistency with the repo's existing full-reload convention.

Closes #365

🤖 Generated with Claude Code

Login signed in client-side then soft-navigated with router.push into
/dashboard, a route the middleware gates on the Supabase session cookie.
The soft navigation can reach the protected route before the server
observes the freshly written cookies, so the middleware bounces it back
to /login -- which looks like the page "just refreshing" instead of
signing in. It surfaced over ngrok/HTTPS tunnels (added latency widens
the window) while staying hidden on localhost.

- login: navigate with window.location.href after signInWithPassword,
  mirroring the deliberate full reload the invite-accept flow already
  uses in join/[token]/page.tsx; drops the now-unused useRouter.
- next.config: allow-list common dev tunnel origins (ngrok, cloudflared,
  localtunnel) so Next 16 stops 403-ing dev-only resources over the
  tunnel, extendable via ALLOWED_DEV_ORIGINS.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@supabase

supabase Bot commented Jul 17, 2026

Copy link
Copy Markdown

This pull request has been ignored for the connected project crxylxakpapcfziradbb because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.


Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

@ArnasDon
ArnasDon merged commit f69c82a into main Jul 17, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[bug] ngrok URL. Clicking the Login button only refreshes the page

1 participant