fix(web): allow /google/callback through auth middleware (Google login bounce) #4070

Originally written by @ccantynz-alt on GitHub.
Imported from https://github.com/ccantynz-alt/AlecRae.com/pull/61

The bug

Google sign-in completes (consent + callback both work) but the user lands back on /login unauthenticated.

Root cause (confirmed in code — not a cookie-domain issue)

Our Google flow hands the session token to the web app via the URL fragment (apps/api/src/routes/auth.ts:381-388 → redirects to mail.alecrae.com/google/callback#token=…). The callback page's client JS reads the fragment and stores the session (completeGoogleSignIn → localStorage["alecrae_api_key"] + alecrae_session cookie).

But the Next.js SSR middleware (apps/web/middleware.ts) guards every non-public path by checking the alecrae_session cookie — and /google/callback was not in PUBLIC_PATHS. So the server-side guard ran before any client JS, saw no cookie (the token is in the fragment, invisible to the server), and redirected to /login. The token was never stored.

Password login works because it sets the cookie on /login (already public) before navigating.

This is not the cross-subdomain cookie theory (Domain=.alecrae.com; SameSite=None): API auth is a Bearer token from localStorage (CORS); the alecrae_session cookie is only the web app's own SSR guard on mail.alecrae.com.

Fix

Add /google/callback to PUBLIC_PATHS so the page's client code runs, persists the session, and routes to /inbox.

How to confirm after deploy

DevTools → Network → sign in with Google → the /google/callback request should now render the page (was previously 307→/login), then land on /inbox authenticated.

https://claude.ai/code/session_01McgJLnTbZG9mwhfwd5iAX3

Generated by Claude Code