Next.js Middleware Missing an Exclusion Forces Login

Conclusion

Next.js middleware (renamed Proxy in Next.js 16) applies whatever condition you write to every route by default. So when you later add a “no login required” route, nothing redirects it away from /login unless you explicitly add that exclusion to the middleware’s own auth condition. Here, a partner-facing public share link (/p/[token], used to view and download invoices and quotes) had been left out of that exclusion.

Symptom

The public share link /p/[token] exists so partners without a login account can view invoices and quotes — it’s meant to work without logging in. Instead, opening it redirected straight to /login before any content rendered, so partners were asked to log in just to see a document that was never supposed to require one.

Cause

Every Next.js request passes through the proxy() function in src/proxy.ts, which checks the Supabase session and redirects to /login when the user isn’t authenticated.

// src/proxy.ts:44-52 (before)
const path = request.nextUrl.pathname;
const isLogin = path === "/login";

if (!isAuthed && !isLogin) {
  const url = request.nextUrl.clone();
  url.pathname = "/login";
  url.search = "";
  return NextResponse.redirect(url);
}

This condition redirects every path except /login itself whenever the user is unauthenticated. The public share route /p/[token] gets no special treatment: since isLogin evaluates to false for it, it falls straight into this branch.

The screen that handles /p/[token] — verifying the token and rendering the document — was already implemented. What was missing was a line in the middleware’s own condition, which runs before that screen, exempting this public route. Because the feature’s implementation and the blanket auth check live in separate files, a working feature can still get swept into /login unless the middleware-side exclusion is added separately.

The fix

Add isPublic, which checks whether path starts with /p/, directly into the auth condition.

// src/proxy.ts:44-53 (after)
const path = request.nextUrl.pathname;
const isLogin = path === "/login";
// External public link (/p/[token]): no login required. Partners view/download invoices and quotes.
const isPublic = path.startsWith("/p/");

if (!isAuthed && !isLogin && !isPublic) {
  const url = request.nextUrl.clone();
  url.pathname = "/login";
  url.search = "";
  return NextResponse.redirect(url);
}

One line, path.startsWith("/p/"), was enough. The key decision was putting that check inside the middleware’s own condition, which every request passes through, rather than in the /p/[token] screen itself — so any future page added under /p/ needs no individual handling.

Making it less likely to recur

This bug was fixed in a single commit, and nothing in the commit history that documents the fix adds a new rule or checklist to prevent the next occurrence. It got fixed because someone noticed, not because a mechanism now catches the next gap.

Structurally, this kind of gap tends to appear when the place that enforces auth for everything (middleware) and the place that implements a no-login feature (each page) live in separate files. Building a new no-login route feels complete once the page itself works, which makes it easy to miss that you also need to go back to proxy.ts and add the exclusion there. In this case, the public share link’s screen was already working fine — only the auth-side condition had failed to catch up.