Feedback Request: Authentication patterns in Next.js

[delbaoliveira]

Hey there. I’m Delba, a Developer Advocate at Vercel 👋

I’ve been working on clarifying how to implement auth in the App Router, including what React and Next.js APIs to use.

While there isn’t one single way to implement auth, there are best practices and patterns to ensure performance and security. This discussion aims to increase our collective understanding of why certain APIs and patterns are better than others.

We are currently documenting these here, and I’ve summarized them below.

I’d appreciate feedback on the proposed patterns, including anything we have not yet considered, and any questions you may have.

Note: While the docs examples show simple password + email auth, our goal isn’t to teach authentication from scratch or recommend that developers create a custom solution, but to give developers an understanding of auth principles so they can choose the best provider or library for their use case.

Terminology

To ensure we use consistent terminology, and to help beginners understand the principles of auth, here’s a quick description of concepts mentioned:

• Authentication - Verifies if the user is who they say they are.
• Session Management - Tracks the user's auth state across requests.
  • Stateless Sessions - session information is stored in the client.
  • Database Sessions - session information is stored in a database.
• Authorization - Decides what parts of your application and data the specific user can access.
• Auth Providers - Refers to third-party solutions that handle authentication and session management. e.g. NextAuth.js, Clerk, Auth0, Lucia, etc.
• Session Management Libraries - Refers to third-party solutions that only provide session management APIs e.g. Jose, Iron Session, etc.

Summary

Here’s a summary of best practices and APIs:

Authentication

• Use forms with Server Actions to implement sign-up and login functionality.
• Form validation should be done before database or external API requests to avoid unnecessary calls.
  • Errors can be handled by the auth provider or a schema validation library (e.g. Zod).
• React’s useFormState() can be used to display validation errors.
• React’s useFormStatus() can be used to handle pending states.

Session Management

• When implementing session management, ensure all cases are handled: encryption, decryption, creating, extending, deleting, and verifying sessions.
• Cookies can be set using the cookies() API.
  • Session data should be encrypted before being stored in a cookie, following best practices.
  • Cookies should be set on the server.
• Use React’s “server-only” package to ensure utils are kept on the server.
• Sessions should contain the minimum necessary user data to make further requests (e.g. user id, role).

Authorization

All parts of your application should be considered when implementing authorization. Unlike SPAs which have a single entry point, allowing you to wrap your app in an auth context provider, Next.js apps have multiple entry points, e.g. Layouts, Pages, Route Handlers, Server Actions.

Middleware

• Good for centralizing redirect logic, allowing you to specify public vs. protected routes.
• Can be used to handle initial checks, but should not be used as the only line of defense.
• Use for stateless checks (optimistic), but not database checks (secure).
  • While it’s ok to read cookies, since Middleware runs on every request (including prefetching), it should not be used for database checks to avoid making multiple calls on each navigation.
  • This aligns with future Partial Prerendering (PPR) patterns, where we may use the presence of a cookie to optimistically rewrite to different pre-rendered shells, e.g. logged-in dashboard shell or logged out shell.
• Uses the Edge runtime - therefore only works with compatible libraries. E.g. works with jose, but not jsonwebtoken.
• redirect() currently cannot be invoked in Middleware. NextResponse.redirect can be used instead.

Data Access Layer

• Strongly recommended for centralizing authorization logic as close to data access as possible,
  • Allows you continually verify the user’s session as they interact with your application.
  • Makes it easier to maintain, audit, and debug your application as it scales.
  • Avoids authorization holes, such as verifying in Layouts which might not be re-render on navigation, or forgeting to check the user is allowed to perform a mutation inside a Server Action.
• Use React’s cache API to memoize the returned values of data requests or your verify/update session utils during a render pass.

Example:

// filename="app/lib/dal.ts"
export async function verifySession() {
  const cookie = cookies().get('session').value
  const session = await decrypt(cookie)

  if (!session.userId) {
    redirect('/login')
  }

  return { isAuth: true, userId: session.userId }
}

export const getUser = cache(async () => {
  const session = await verifySession()
  if (!session) return null

  try {
    // fetch data
  } catch (error) {
    // ...
  }
})

Data Transfer Objects

• When fetching data, only return the data needed for the specific requests and not whole objects that might include data you don’t want to expose to the client. e.g. personal contact information.
• If you cannot control the data structure, specify the fields that are ok to be exposed on the client.

Example:

// filename="app/lib/dto.ts"

import { getUser } from '@/app/lib/dal'

function canSeeUsername(viewer: User) {
  return true
}

function canSeePhoneNumber(viewer: User, team: string) {
  return viewer.isAdmin || team === viewer.team
}

export async function getProfileDTO(slug: string) {
  const data = await db.query.users.findMany({
    where: eq(users.slug, slug),
    // Return specific columns here
  })
  const user = data[0]

  const currentUser = await getUser(user.id)

  // Or return only what's specific to the query here
  return {
    username: canSeeUsername(currentUser) ? user.username : null,
    phonenumber: canSeePhoneNumber(currentUser, user.team)
      ? user.phonenumber
      : null,
  }
}

Server Components and Layouts

• Good for conditionally rendering UI based on the user’s role.
  • Since Server Components execute on the server, only the result of the render is sent to the client.
  • Advanced pattern: See [conditional routes](https://nextjs.org/docs/app/building-your-application/routing/parallel-routes#conditional-routes).
• Not recommended as your main auth check (see Layouts), use a Data Access Layer instead.

Example:

// filename="app/dashboard/page.tsx" 

import { getSession } from '@/app/lib/dal'

export default function Dashboard() {
  const session = await getSession()
  const userRole = session?.role

  if (userRole === 'admin') {
    return <AdminDashboard />
  } else if (userRole === 'user') {
    return <UserDashboard />
  } else {
    redirect('/login')
  }
}

Layouts

• Layout do not re-render on navigation, therefore are not recommend for auth checks. Consider a shared navigation that displays user information:

❌ You may be tempted to check the user’s auth state, then fetch data:

// filename="app/layout.tsx" switcher

export default async function Layout({ children }) {
  const { userId } = verifySession()
  const user = getUser(userId)

  return (
    // ...
  )
}

✅ Instead, check the auth state in a Data Access Layer. This guarantees that wherever getUser() is called within your application, the auth check is performed.

// filename="app/layout.js" 

import { getUser } from '@/app/lib/dal'

export default async function Layout({ children }) {
  const user = await getUser();

  return (
    // ...
  )
}

// filename="app/lib/dal.js"

export const getUser = cache(async () => {
  const session = await verifySession()
  if (!session) return null

  try {
    // fetch data
  } catch (error) {
    // ... 
  }
})

Client Components and Context Providers

• Context providers work due to interleaving. However, React context is not supported in Server Components, making them only applicable to Client Components.
• If session data is needed in Client Components (e.g. client-side data fetching), auth libraries can expose client-safe hooks.
• Use React’s taintUniqueValue API to prevent sensitive session data from being exposed to the client.

This works, however, any children Server Components will be rendered on the server first, and will not have access to the context provider’s session data:

import { ContextProvider } from 'auth-lib'

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        <ContextProvider>{children}</ContextProvider>
      </body>
    </html>
  )
}

"use client";

import { useSession } from "auth-lib";
 
export default function Profile() {
  const { userId } = useSession();
  const { data } = useSWR(`/api/user/${userId}`, fetcher)
 
  return (
    // ... 
  );
}

Currently exploring ways to read session data on the server, and pass it to the client. Suggestions welcome.

Server Actions and Route Handlers

Treat Server Actions and Route Handles with the same security considerations as public API endpoints. Always verify user is allowed to perform the action before continuing.

Example:

'use server'

import { verifySession } from '@/app/lib/dal'

export async function serverAction(formData: FormData) {
  const session = await verifySession()
  const userRole = session?.user?.role

  // Return early if the user is not authorized to perform the action
  if (userRole !== 'admin') {
    return null
  }

  // Proceed with the action for authorized users
}

---

Finally, this rough diagram shows an overview of the possible auth paths in Next.js, highlighting React and Next.js APIs used.

[alvarlagerlof]

I'm curious about patterns for authed-only data fetching functions when tokens need to be refreshed (and haven't expired), and the client should get updated cookies.

[delbaoliveira]

Yes, that's a good use case to cover 👍🏼

[HOSS11H]

I'm curious about that, too. Had a lot of time trying to apply refresh token rotation with Next Auth and reached a dead end as it appears to be a Next js app router problem

[mdavish]

This is extremely helpful! Thanks for putting it together. A couple questions -

Could you elaborate a little more on why layouts aren't sufficient for protecting parts of your app? Right now we are checking for that the user is authorized inside of our /dashboard/[accountId] route, but then all of the more deeply nested routes e.g. /dashboard/[accountId]/settings do not check for user privileges, because we just assume that if the user is on that page, they must be authorized to see it.

This has been very convenient because most developers don't have to think about auth while adding new pages, but it sounds like this opens up a vulnerability, so I'd like to understand more why that's not recommended. It sounds like the vulnerability exists because the layout doesn't re-render when the user navigates, so technically a user could have their permissions revoked and still see the app as long as they don't close their browser? Is that it?

My other question is around server actions. We assume that all server actions should be protected as if they were regular old POST endpoints accessible by anyone. Is that accurate and could you elaborate a little more on the recommended approach for protecting server actions?

[jescalan]

Pages can be rendered without layouts, so adding an auth check to a layout is not enough to protect its contents. If you are trying to protect a page, you must check for auth on that page itself before rendering content. You can verify this by making a request to any of the pages that you feel are protected by layout auth in your app, and adding a RSC=1 header to your request - you will see that it returns the content without any auth checks. If you are trying to protect page contents by adding auth to a layout in your app, this is a security vulnerability and you should patch it as quickly as you can.

For server actions, to make sure you are clear, you want to make sure that you have an auth check inside your server action, not inside a page that the server action runs on, or a layout within which the server action gets run. Even if the server action is only used on a single page, it's still deployed as a standalone route that can be accessed publicly, so it must have its own internal auth check to be considered secure.

Hope this helps 🙏

[delbaoliveira]

Hey @mdavish

So technically a user could have their permissions revoked and still see the app as long as they don't close their browser? Is that it?

Yes, and it's following the general principle that data access should be determined where you fetch data to prevent things from moving out of sync. One of the examples you gave is partial rendering, but a different developer could naively also import your data function outside your protected layout.

We assume that all server actions should be protected as if they were regular old POST endpoints accessible by anyone. Is that accurate

Yes, that's correct.

could you elaborate a little more on the recommended approach for protecting server actions?

It's not hugely different from patterns you might be used to, check the user is allowed to perform a mutation before executing it.

[mdavish]

Thanks guys! Didn't realize that about layouts. We will patch this ASAP!

[colinclerk]

👋 Colin from Clerk here

The two mistakes we see most for authorization are:

1. Developers assuming return null from layout will block all nested page and server action access. (Notably - the strategy of returning null from a parent component blocked child components entirely in CSR/SSR, but not RSC.)
2. Developers assuming return null from the top of a page blocks access to an embedded server action.

We'd love to see a first-class authorization pattern that mitigated these mistakes, in addition to education.

[delbaoliveira]

Strong points, thank you 🙏🏼

[AhmedBaset]

How return null from the top layout doesn't block nested pages?

[kylemh]

I think a LOT of people use Cognito because it's thought of as the cheapest and most reputable auth provider in the game. I also think a lot of people would end up using Amplify for a simpler SDK to work against Cognito with.

The v6 announcement post celebrates support of Next.js middleware which is great news for probably many companies who have single region servers (and maybe the decision to be multi-region is not in their control), but have an opportunity to be edge-first for authentication. The example in their blog post even does auth-gated routing!

But @sebmarkbage suggests that nobody should be doing that and Middleware isn't the place for auth checks. I just assume I'm doing it wrong, so I'm excited for this discussion and the documentation it will yield... but I'm hoping that the ideal option(s) are as simple as adding an auth gate to middleware 😂

For now, I'm stuck doing client-side only authentication if I'm not meant to be authenticating via middleware. I have content that's static (not dynamic), but auth-protected... So, PPR incoming means I guess I'd just add auth to each and every one of my RSCs? If that's the case, I'd want to know if there's a simple way for me to hide all the content of the static page until the first authenticated request of any RSC on the route is successful? It doesn't seem like that'd be viable.

[icyJoseph]

But @sebmarkbage suggests that nobody should be doing that and Middleware isn't the place for auth checks. I just assume I'm doing it wrong, so I'm excited for this discussion and the documentation it will yield... but I'm hoping that the ideal option(s) are as simple as adding an auth gate to middleware 😂

I have thought about this over night, before just answering raw, but I really think he's saying that, because, the piece of code that's actually Reading or Mutating the protected data, could still be run independently from the Middleware check.

Defensive programming has to be the norm.

And someone gaining the ability to trigger that piece of code, outside of the middleware flow, either by developer or framework mistake, would have free range to do anything to do the unprotected data.

This can just be someone adding an early return or, changing the matcher, or straight up removing the middleware as part of another work unit.

So at middleware level, yes, you can check if a user needs to be prompted for authentication, but then, when reading/writing data, you should run the verification again, some systems, require an even stronger level of authentication to mutate data, that they do to read, and that's but a defense mechanism to prevent human errors.

The post you shared here, https://aws.amazon.com/blogs/mobile/amplify-javascript-v6/, also shows that when accessing data, they use the cookies header, and that middleware is only used to let the request continue, or redirect to login. And I'd guess that the cookie is used by the GraphQL service to see if the operation is allowed, which is Seb's point I guess.

• https://nextjs.org/blog/security-nextjs-server-components-actions

[eric-burel]

My 2 cents (edit: more 10 cents the more I think about it), as the author of the article @sebmarkbage answered to:

• the point if middleware-only auth check is to avoid dynamic rendering, so PPR is not a solution here, you'd still have dynamic rendering for the protected component, you just move the issue from the whole page to specific components (edit: at least for PPR as dynamic components within static shell, Delba's post seems to mention that it could bring more advanced patterns that I am not yet knowledgeable about, so maybe it could become relevant actually)
• it's a relatively specific pattern, the main use case being implementing paywalls, more broadly protecting content that is the same for many users, I don't advocate using it everywhere
• keep in mind that we are talking about edge middlewares here, which is a specific kind of proxy server. It's easy to get the matchers wrong for instance and to accidentally let slip some data => data layer auth check will always be safer. It can perhaps be better to use a more advanced proxy server with a safer setup.
• a custom server can also be used with the same goal if you don't need serverless/edge features and you self-host Next
• the gain of avoiding dynamic renders is debated. I think it's the "right" thing to do and that's why I've been a long time proponent of personalized static rendering using middlewares (protected static pages is one specific example of that), however a React render is relatively cheap compared to fetching data => you get significantly more value from caching your fetch calls eg using unstable_cache than using static rendering. This opinion is for instance prevalent in the Remix ecosystem, which focuses on introducing data caching and do not yet have a built-in pre-rendering system
• HTTP cache, that is sometimes proposed as an alternative to static rendering, doesn't work for private content. The ability to do middleware protection/redirection makes Next able to statically render more content than you can do with just an HTTP cache.
• "While it’s ok to read cookies, since Middleware runs on every request (including prefetching), it should not be used for database checks to avoid making multiple calls on each navigation." => true I didn't think about this counter-argument, you don't have one run per page load but one run per request so it's hard to do one check per navigation. However authentication doesn't always involve a database check, if you are using self-contained JWT tokens with a short lifetime, as opposed to session-based auth you don't need a database call (I've written about that in a attempt to better differentiate these patterns).
• It might be difficult to protect JS chunks for protected pages, because you need at least a bit of JS to make your auth page work properly. The _next files do not seem to include rendered data last time I've checked, but still an issue.

To sum it up, in theory, checking auth before hitting a statically rendered page is the most optimal approach. In practice, edge middleware are perhaps a tad too limited here, if your content is super secure you may want to accept dynamic rendering. For a paywall in front of a small-sized blog, that's relatively acceptable, at worse people access your blog post without paying but you don't lose user data etc.

Related discussion on Astro github: withastro/roadmap#869 (comment)

[eric-burel]

Also Vercel and other host should just sell a paywall feature, if you are finicky enough to want static rendering for your paid/protected content you are most probably ok to pay a few bucks per month to get a paywall. I didn't meet this feature in the host I've used so far.

[colinclerk]

Instead of explicit Data Transfer Objects, is it acceptable to modify toJSON() to prevent sensitive data from being serialized? This appears to work today, but it's not documented as an approved approach.

[delbaoliveira]

In general, I think the principle is important, not the specific method. We don't want to be too prescriptive.

[pkellner]

I’d be nervous about using any cache for any requests having to do with security. I’d say as a rule don’t cache any auth headers.

[alfonsusac]

React's cache only live for one single request. its only job is to deduplicate multiple function calls into one. It will not bleed to other user since the cache only live within a single request therefore shuld have nothing to do with security.

Think react's cache() as a request.context from express-js. Though I agree, the name can sound intimidating for stuff as sensitive as auth.

[pkellner]

@alfonsusac , I get why you need to cache async external calls during a single request and the need for cache there, but I'm not understanding why you'd need to cache something that is, I'm assuming, already in memory because it's from a local header.

Regardless, if you use the words cache and security headers, you will make security auditor a huge pile of billable hours, even if ultimately you show that it's not a risk.

I'd strongly think about how not to "cache" auth credentials.

[alfonsusac]

If I have 3 layout.js and 1 page.js that calls for getUser() in a single request, would it be ok to decrypt my tokens 4 times even though theyre ultimately the same?

The point of React's cache() (which i agree is a terrible name) is to only dedupe those 4 redundant function calls into one. Only the cookies and the header are "in memory" the rest, decrpytion, and getting the user data still needs to be performed manually.

Would you be okay if the "cache()" function is renamed into "dedupe()"? Its sterns from then need to be able to use reusable function to get data everywhere in the render pass without passing down props to props to props.

i.e calling this 3 consecutive times
await getUserData()
await getUserData()
await getUserData()
cookies would only be decrypted once.

I think any other caching method Next.js offers would be bad if used with auth credentials, thus I agree with you. But React's cache is entirely for a different purpose.

[icyJoseph]

The React cache is a way to store a computation, for the ongoing ssr render pass, and that can just be a network call result, or the 39th Fibonnaci number. cache is just a loaded word I guess.

AsyncLocalStorage is also a way to do this in Node.js

dedupe is also not great, because one can store containers (Map, {}, Set, etc) there, and access those as a kind of server context, throughout the ongoing render pass.

cache as a primitive is great, but maybe there should've been a Next.js wrapper API, something like, requestContext, with setters and getters, built around cache. And yes, requestContext is also not really 100% accurate, as build time render passes would also use it.

[eric-burel]

React cache is fine, however unstable_cache bearing almost the same name is a footgun. Initially I thought it was a more advanced kind of cache, later on I figured that it was shared across requests (while React cache will always be scoped to a single request).
I'd advocate for a clearer name like "shared_cache", and in the meantime this should be made super visible in the doc in my opinion.

[giovanni-depalma]

1. Why is the middleware placed in the client section in the diagram, and it seems not to intercept the server actions/route handlers?
2. In the Server Actions and Route Handlers example, it is indicated to ALWAYS verify the session. If there's an appropriately configured middleware, is this enough as the first line, leaving the session control to the data access layer?
3. Not strictly related to the auth topic, I hope that we can soon use useActionState instead of useFormState/useFormStatus.

PS: I am very pleased and grateful for this thread. I have recently completed an integration with next-auth, but it's better to clarify things.

[alfonsusac]

The middleware isn't supposed to be used as the full session checking strategy. Here in Next.js middleware needs to be as lightweight as possible. Therefore it only checks for session and not database access. You can filter this by only intercepting initial page navigation and not server action and route handlers.

Further checks can be done inside server action/route handlers and server components and along side it check if the user is valid in the database (making database connection) which is the true auth guard for this setup. Just like getServerSession() (I'm sure you're familiar with that)

Session checking is one thing, and its job is only identifying the ID of the user. But the state of the user is stored in the Database. Thats why to identify and check, for example, if this user has paid for the content or not needs to be done elsewhere outside of the Middleware since the Middleware isn't supposed to do database connection.

P.S. correct me if im wrong or ask more questions

[giovanni-depalma]

The problem is that by following these rules, I would have:

Server Actions

'use server'

import { verifySession } from '@/app/lib/dal'

export async function addTodoAction(formData: FormData) {
  const session = await verifySession()
  const userRole = session?.user?.role
  // Return early if the user is not authorized to perform the action
  if (userRole !== 'admin') {
    return null
  }
  dal.addToto();
}

and in the

Data Access Layer

export async function addToto(){
 const session = await verifySession()
  const userRole = session?.user?.role
  // Return early if the user is not authorized to perform the action
  if (userRole !== 'admin') {
    return null
  }
  //proceed
}

If we don't perform the checks in the data access layer, we would be violating the main rule of conducting checks there (Strongly recommended for centralizing authorization logic as close to data access as possible).

Therefore, either they are two different checks, or it becomes a duplication. Upholding the principle of control over the DAL, I was referring to a first line of defense through middleware (session based), leaving the real check to the data access layer.

[alfonsusac]

The duplication is fine if verifySession is wrapped with react's cache. It will only be run once.

Two line of defense was through middleware, which can be Edge based, is faster to atleast process users without session,
The next line of defense is the DAL which is the ultimate auth guard with full correctness.

So its less of a line of defense but instead to pre-filter users with no session token without ever going to the DAL.

[giovanni-depalma]

My concern wasn't about performance, but about the quality of the code, especially when the duplication is so "close." In any case, it results in more code to write, maintain, and test. Generally, I think duplication is acceptable, but it should be justified to avoid any doubts.

[alfonsusac]

You can still have separations of concerns and intercepts operations of any DAL before it ever reaches the CRUD part. Here in the example since profile DTO is partially public, they access the prsima first and get the user to filter out which they can or cannot see.

If you want to do mutation, you can simply add the getUser() function before any CUD operations.

Server Actions

'use server'

import { verifySession } from '@/app/lib/dal'

export async function addTodoAction(formData: FormData) {
  dal.addToto();
}

Data Access Layer

export async function addToto(){
 const session = await verifySession()
  const userRole = session?.user?.role
  // Return early if the user is not authorized to perform the action
  if (userRole !== 'admin') {
    return null
  }
  //proceed
}

[devajakamerus]

These would be useful:

Providing configurable option for supporting nodejs middleware. You can easily achieve this by editing a few files but of course relying on source edits is not good for production code. But still there's no reason middleware can't be arbitrary code IF it's running on nodejs.

An initialization script ( would be basically same than middleware if single server) that can provide data for any subsequent functions using asynclocalstorage. Basically like how headers and cookies are accessed but for user data object ( or basically any data). This would make it easier to do one auth check at the start and then access the auth status/user data anywhere else directly if needed. Also it's much more secure to have it in one place than relying on checks littered over the codebase. Also component code could be more synchronous when user/auth data can be accessed directly and not thru some async getSession method.

Also for auth libraries it would be easier to have such single standard point to hook into. "do your check, save results here in this format". That would also provide an abstraction for the auth implementation so changing auth library wouldn't require any changes elsewhere.

[rwieruch]

Hey there! Thanks for this extensive writeup @delbaoliveira 💯

FWIW I have written a comprehensive tutorial about using Lucia Auth in Next 14 and its App Router. I followed the best practices provided by Lucia, but I wasn't super sure about authorization in Layouts vs Middleware. Related discussion that I started: lucia-auth/lucia#1469

Perhaps this piece from @pilcrowonpaper should be taken into the discussion too: https://pilcrowonpaper.com/blog/middleware-auth/

[eric-burel]

Hi, I am not sure there is a debate about auth in middleware vs layout, layouts are just not suited at all for auth because they can be bypassed, by design
The debate would be about doing auth when accessing data (implying a dynamic render even for data common to multiple users), which is currently the recommended way, versus authenticating in a middleware to allow having a protected static renders, which is suited for some specific use cases like crafting a paywall for ablog but is debated (the perf gain may be not that great if the auth check requires a db call at the edge ; it makes human errors more critical)

[eric-burel]

Regarding Pilcrow's article it mentions any kind of top level auth check however the arguments are mostly built on the example of top level middlewares like "app.use" in Express, I don't think the arguments truly apply to edge middlewares or proxy server. We don't do edge middleware auth for dryness, but because that's the only way to protect a static render. There is no concept of top level middlewares for route handlers and API routes either.

[williamlmao]

Hi @delbaoliveira, thanks for this write up. A couple clarifying questions:

Is it okay to then pass the user from this layout.tsx, down to a client provider?

import { getUser } from '@/app/lib/dal'

export default async function Layout({ children }) {
const user = await getUser();

return (

{children}

)
}

Why does moving the getUser() to a different file make any difference?
You state:

Layout do not re-render on navigation, therefore are not recommend for auth checks. Consider a shared navigation that displays user information:

But then your example shows

✅ Instead, check the auth state in a Data Access Layer. This guarantees that wherever getUser() is called within your application, the auth check is performed.

// filename="app/layout.js" 

import { getUser } from '@/app/lib/dal'

export default async function Layout({ children }) {
  const user = await getUser();

  return (
    // ...
  )
}
// filename="app/lib/dal.js"

export const getUser = cache(async () => {
  const session = await verifySession()
  if (!session) return null

  try {
    // fetch data
  } catch (error) {
    // ... 
  }
})

This may just be a lack of understanding on my part, but I don't understand why moving getUser() out to a separate file makes any difference here, when you say the issue is that layouts do not re-render on navigation. Is it just that wrapping getUser in cache() that makes the difference here? Even then, I don't understand how that solves the issue with layout.tsx not re-rendering on navigation.

Thank you!

[ritik48]

@williamlmao hey, did you find the reason for separating the getUser() function to different file ?

[kylemh]

I'm not Delba, but I think the distinction is:

• Don't call the auth-relevant fn once in the layout file because re-renders don't occur.
• You can use auth-relevant fns in the layout file for things in the layout which require it to render, but by externalizing that logic as a DTO, you'll probably use it in components that DO re-render.

It's just a coincidence that the DTO is required to be in a different file because of the rules on exporting things from within a layout component file and not the main point of the comparison.

[ritik48]

So, it means we have getUser in its own file just to abstract away the logic for checking the session and handling cases where it doesn't exist, right?

I'm facing an issue related to this concept. I have a Navbar (server component) that is part of my layout, and I pass the session data to it, which I obtain within the layout itself. Based on the session, I render links like "Login" and "Logout" in the Navbar.

The problem is that when the session expires and I navigate around the app, my route handler redirects me to the / route using the redirect() function from next/navigation. However, the Navbar state doesn't update to reflect the expired session.

I understand that this happens because the layout component doesn’t re-render. What's the workaround for this? How can I update the Navbar when the session expires ? I also tried to make the Navbar a Client Component, but it seems useSession too don't have the updated session.

Can you please tell me how to fix this ? Thanks.

[kylemh]

I believe that's covered above the spot where it says "Currently exploring ways to read session data on the server, and pass it to the client. Suggestions welcome."

You'll want the part of the NavBar reading user data to be a client component that uses some
sort of data fetching tool which can be seeded via server data, but also revalidates client-side so that it'll re-render.

Alternatively, you'll need to
revalidate: https://nextjs.org/docs/app/building-your-application/data-fetching/caching-and-revalidating but I'm uncertain if revalidating routes even works with layout components and their children

[mtilda]

Is the use of taintUniqueValue necessary/safe considering it is an experimental feature?

I see it being used in the examples/sanity-cms, as shown below:

next.js/examples/cms-sanity/sanity/lib/token.ts

Lines 11 to 15 in 9a1cd35

	experimental_taintUniqueValue(
	"Do not pass the sanity API read token to the client.",
	process,
	token,
	);

In this example, if I remove the above code, will Next.js expose my API token?

As far as I can tell (see my GitHub search), this is the only experimental feature used in this example, so it would be my only reason for switching to an experimental version of React.

The React API reference for experimental_taintUniqueValue clearly warns "Experimental versions of React may contain bugs. Don’t use them in production."