Really trying to setup PPR with no sucess, <Link> navigation not respecting my page AUTH

[tadeumaia]

Summary

I'm trying to enable and understand PPR on my project.
All my clicks are redirecting me to my /sign-in page, I have no idea why, I could use some guidance to debug this.

I only check and redirect to sign-in in 2 places:

1. Middlware using supabase SSR
2. At the very beggining of each and every app router page

If I navigate directly it works, but navigation using my link it falls into my page auth guard, which to my understanding seem to be the recomended way of doing auth according to nextjs guide.

Additional information

This is a sample of my code 


... await checkPageAcess() //start of every page.tsx

export async function checkPageAccess(permissions: PagePermissions = {}): Promise<PageAccessResult> {

 const user = await getUserAuth();

    // Basic authentication check
    if (permissions.requiresAuth !== false && !user) {
      redirect("/sign-in"); <- link falls here, verified by changing this to another url and being redirect there
    }

    // Team existence check - every user must have a team
    if (!user.team) {
      // User without team is an invalid state - redirect to sign-in
      redirect("/sign-in");
    }

and 

export async function getUserAuth(): Promise<UserAuth | null> {
  try {
    const session = await verifySession();
    if (!session) {
      return null;
    }

    // Get cached user data from DB
    const userData = await getCachedUserData(session.sub);
    if (!userData || !userData.team_members || userData.team_members.length === 0) {
      return null;
    }

    // Get subdomain and tenant cookie for team resolution
    const subdomain = (await headers()).get("X-Subdomain");
    const cookieStore = await cookies();
    const tenantCookie = cookieStore.get("tenant")?.value;

    // Transform to UserAuth
    return await transformToUserAuth(userData, subdomain, tenantCookie);
  } catch (error) {
    captureError(error, {
      operation: "getUserAuth",
      extra: {
        error: error instanceof Error ? error.message : String(error),
      },
    });
    return null;
  }
}

// verify the user session
export const verifySession = cache(async () => {
  const supabase = await createClient();
  const { data } = await supabase.auth.getClaims();

  const claims = data?.claims;
  if (!claims || !claims.sub) {
    return null;
  }

  return claims;
});

Example

No response

[CoderDeltaLAN]

Context

• Next.js 15 (PPR enabled)
• <Link> navigation reaches a page that should require auth
• It works on hard refresh but not on client navigation

Why
With PPR the shell can be prerendered and cached. If the auth check runs only on the client or the page is cacheable, the client navigation may reuse cached HTML and bypass your guard.

Fix (minimum viable)

1. Enforce server-side auth check in the page/layout and make it dynamic:

// app/(protected)/dashboard/page.tsx
import { cookies } from 'next/headers'
import { redirect } from 'next/navigation'

// prevent caching of this route
export const dynamic = 'force-dynamic'        // or: export const revalidate = 0

export default async function Page() {
  const token = cookies().get('session')?.value
  if (!token) redirect('/login')
  return <main>Private</main>
}

2. Mark your data as non-cacheable if you fetch user/session:

await fetch('https://api.example.com/me', { cache: 'no-store' })

3. Do not rely on client-only guards (e.g. useEffect + redirect). They run too late for PPR and allow a flash or reuse cached shell.

4. Optional edge gate for global protection:

// middleware.ts at project root
import { NextResponse } from 'next/server'
export function middleware(req: Request) {
  const has = req.headers.get('cookie')?.includes('session=')
  if (!has && req.url.includes('/dashboard')) {
    return NextResponse.redirect(new URL('/login', req.url))
  }
  return NextResponse.next()
}
export const config = { matcher: ['/dashboard/:path*'] }

Checklist

• Protected routes: dynamic='force-dynamic' or revalidate=0
• Server check with cookies()/headers() + redirect()
• Any auth-related fetch: cache: 'no-store'
• Optional middleware for belt-and-suspenders

Docs

• PPR overview: https://nextjs.org/docs/app/building-your-application/rendering/partial-prerendering
• Dynamic rendering: https://nextjs.org/docs/app/building-your-application/rendering/server-components#dynamic-rendering
• Route middleware: https://nextjs.org/docs/app/building-your-application/routing/middleware
• redirect and cookies: https://nextjs.org/docs/app/api-reference/functions/redirect , https://nextjs.org/docs/app/api-reference/functions/cookies

If this solves it, please Mark as answer so others can find it.

[tadeumaia]

Thanks for the reply, but while this is a comprehensive I do not think this does have anything to do with my problem.

• I'm not using anything CLIENT side like useEffect for client guard, as stated on my post this is all server side and the checks are right at the start of page.tsx
• I'm not using fetch for anything
• As fas as I know auth on layout is a nono
• As far as I know checking cookie make it dynamic already

[icyJoseph]

Are you able to put some logging? When is the redirect being calculated? On navigation? or is it prefetched? Are you using ppr only? The feature should be used with cacheComponents.

My guess would be that the static shell for this pages is hitting the redirect cuz it is being made without dynamicIO enabled - please do try with cacheComponents. I'll try to make reproduction (if you can setup a minimal repro I'd appreciate that)

[tadeumaia]

Hello @icyJoseph, Thanks for the assist. I'll try to cacheComponents on now instead of ppr:true and get back to you. If this does not solve it I will try to create a reproduction.

[CoderDeltaLAN]

Thanks for bringing this up. What Joseph mentioned about cacheComponents and dynamicIO is spot-on, but to tie it back to your original problem:

When you use PPR with <Link> navigation, the redirect/auth logic can get skipped if the static shell is served without dynamic IO. That’s why the redirect might not trigger as you expect.

A couple of things you can try:

1. Add logging inside your auth/redirect function so you can confirm when it runs (prefetch vs navigation).
2. Enable dynamicIO or combine PPR with cacheComponents — this ensures the redirect is respected even when the shell is cached.
3. If possible, try a minimal repro with just the auth redirect + PPR. That helps confirm whether it’s config-related or something in your app logic.

In short: the fix is usually making sure dynamicIO is on and that the page/components are cached consistently. Otherwise the shell hits before your redirect runs.

Did enabling dynamicIO with cacheComponents solve the issue on your side?

[icyJoseph]

cacheComponents includes dynamicIO, furthermore the dynamicIO flag is no longer a thing.

[CoderDeltaLAN]

I had a similar issue with PPR and <Link>. The redirect was being triggered during prefetch. Switching the page to use cacheComponents fixed it, since it already includes the new dynamicIO.