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

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>

next.config.ts

@@ -64,6 +64,34 @@ const SECURITY_HEADERS = [
 ] as const;
 
 const nextConfig: NextConfig = {
+  /**
+   * Cross-origin dev access (Next.js 16).
+   *
+   * Next 16 blocks requests to dev-only resources (`/_next/*` internals,
+   * the HMR websocket, the dev overlay) unless the browser's Origin is
+   * the host the dev server booted on — `localhost` by default. Tunnels
+   * like ngrok serve the app from a public HTTPS host, so without
+   * allow-listing that host those dev requests come back 403: HMR stops
+   * working and the dev session degrades over the tunnel (issue #365).
+   *
+   * Wildcards match subdomains only (Next's CSRF matcher), so the
+   * randomised tunnel subdomain is covered. Add any other host via
+   * `ALLOWED_DEV_ORIGINS` (comma-separated). This key is dev-only and
+   * has no effect on a production build.
+   */
+  allowedDevOrigins: [
+    "*.ngrok-free.app",
+    "*.ngrok.app",
+    "*.ngrok.io",
+    "*.trycloudflare.com",
+    "*.loca.lt",
+    ...(process.env.ALLOWED_DEV_ORIGINS
+      ? process.env.ALLOWED_DEV_ORIGINS.split(",")
+          .map((origin) => origin.trim())
+          .filter(Boolean)
+      : []),
+  ],
+
   /**
    * Cache-Control policy.
    *

src/app/(auth)/login/page.tsx

@@ -1,7 +1,7 @@
 "use client";
 
 import { Suspense, useState } from "react";
-import { useRouter, useSearchParams } from "next/navigation";
+import { useSearchParams } from "next/navigation";
 import Link from "next/link";
 import { useTranslations } from "next-intl";
 import { createClient } from "@/lib/supabase/client";
@@ -42,7 +42,6 @@ function LoginPageInner() {
   const [password, setPassword] = useState("");
   const [error, setError] = useState<string | null>(null);
   const [loading, setLoading] = useState(false);
-  const router = useRouter();
   const supabase = createClient();
 
   const handleLogin = async (e: React.FormEvent) => {
@@ -61,11 +60,18 @@ function LoginPageInner() {
       return;
     }
 
-    if (inviteToken) {
+    // Full-page navigation (not router.push) so the browser issues a
-      router.push(`/join/${encodeURIComponent(inviteToken)}`);
+    // fresh top-level request that carries the just-written Supabase
-    } else {
+    // auth cookies to the middleware gating /dashboard. A soft
-      router.push("/dashboard");
+    // client-side navigation can reach the protected route before the
-    }
+    // server observes the new session, so the middleware bounces it
+    // back to /login — which looks like the page "just refreshing"
+    // instead of signing in (issue #365). Mirrors the deliberate full
+    // reload the invite-accept flow already uses in join/[token].
+    const destination = inviteToken
+      ? `/join/${encodeURIComponent(inviteToken)}`
+      : "/dashboard";
+    window.location.href = destination;
   };
 
   return (