Add set method to cookies function in Server Components

[dijonmusters]

Goals

1. Simplify logic when doing SSR auth with cookies
2. Reduce the overhead of using middleware just to set a refreshed cookie
3. Reduce the developer overhead understanding the differences between handling cookies in Server Actions, Route Handlers and Server Components

Non-Goals

Background

When using an authentication service - such as Supabase, NextAuth or Auth0 - it is likely that a session would need to be refreshed before making a request for protected data from a Server Component. Since the cookies function from next/headers only provides read access to cookies in Server Components, those routes need to be wrapped by a middleware.ts function, whose only purpose is to set the cookie for a refreshed session.

With the introduction of writable cookies in Server Actions and Route Handlers, middleware is no longer required, simplifying the DX of working with cookies.

If Server Components were able to call the set method on the cookies function, then cookies could be handled in exactly the same way across Server Actions, Server Components and Route Handlers. This means middleware could be used to solely implement middleware, rather than enabling write access for cookies on routes that happen to be Server Components, rather than Server Actions or Route Handlers, the understanding of which, requires a deep knowledge of Next.js and the App Router.

From the standpoint of services trying to build libraries to make auth more seamless with Next.js, this would mean we could treat all the new server-side bits in the App Router the same, improving the overall DX of implementing auth.

Proposal

Allow Server Components to call the set method on the cookies function from next/headers

[brotheroftux]

Any updates on this? cookies().set() is only available in Route Handlers and Server Actions right now. I would really like to have an ability to opaquely (for client) manipulate request headers/cookies, since that would simplify token refresh procedures when using colocated data fetching. Currently I have to resort to throwing away a reissued access token while also hoping that some client side fetch operation would follow, refreshing an access token and getting an actual cookie back.

[moshest]

I agree. The current support for cookies is a disaster.

I understand why cookies().set() can't support server components, as something the response already sent, but it doesn't mean we can't pass the request to the client and execute it there.

In general, useCookies hook for client components will save so much work for SSR applications.

[moshest]

I created this package to solve this problem:

'use client';

import { useCookies } from 'next-client-cookies';

const MyComponent = () => {
  const cookies = useCookies();

  return (
    <div>
      <p>My cookie value: {cookies.get('my-cookie')}</p>

      <button onClick={() => cookies.set('my-cookie', 'my-value')}>
        Set cookie
      </button>
      {' | '}
      <button onClick={() => cookies.delete('my-cookie')}>Delete cookie</button>
    </div>
  );
};

It's fully supported both by client components, SSR and server components. See more details on the package readme.

[joaosousafranco]

This is not correct for httponly cookies. httponly cookies can only be set in server side.

[fobos531]

@leerob Could you perhaps shed some insight on what was the reasoning behind this decision/constraint?

[leerob]

Server Components can't introduce side effects, so it's important to ensure the output remains consistent given the same input. Setting cookies is a side effect. So, to set a cookie, you must use either Server Actions, Middleware, or Route Handlers. This is my understanding.

[fobos531]

Server Components can't introduce side effects, so it's important to ensure the output remains consistent given the same input. Setting cookies is a side effect. So, to set a cookie, you must use either Server Actions, Middleware, or Route Handlers. This is my understanding.

@leerob

Hmm, interesting take, thanks! Since this is indeed available in Pages router, can you highlight an example of where exposing this functionality server-side produced unexpected consequences? I guess what I'm asking is why it's bad for server components to introduce side effects - I mean you mentioned "to ensure the output remains consistent given the same input", but I'm not sure I quite understand the context behind this. Is there a piece of documentation (or perhaps a tech blog/youtube video) that covers this argument?

Finally, I think you're doing a great effort with the App Router Incremental Adoption Guide, and I really like how you've broken it down by sections. What I think is missing and would be a great addition is things like these: missing router.pathname (pathname with slugs and route segments as defined by the directory structure, NOT the actual pathname visible in addressbar), not being able to set cookies in Server components etc. Having these covered in the incremental adoption guide as well would be huge. The closest I've seen is for example: https://nextjs.org/docs/app/building-your-application/upgrading/app-router-migration#accessing-request-object

There, it is mentioned:

For example, you can retrieve the req object from getServerSideProps and use it to retrieve the request's cookies and headers

However, this paragraph fails to mention that it was also possible to set the cookies (among other things) server side. I'm sure there were a handful of cases when this was useful - and since this was "removed" (i.e. not available in server components), I think it would be immensely helpful if right in that place it was mentioned why this was done and what is the alternative path to do so. On the example of cookies, you mention Server Actions/Middleware/Route handlers, but I'm curious in some alternative use cases like e.g. setting cart (e-commerce) cookies on initial app load (accomplished by app.GetInitialProps in pages router). I don't think Server Actions/Middleware/Route handlers are 100% appropriate for the way this would be done via GetInitialProps, so I'm curious what approach would you recommend in the App router. Do you simply suggest to do this client-side instead of server-side, or is there a piece of the puzzle that I'm failing to see?

[moshest]

I think I can relay with @leerob. React components in general should not make changes unless the user use useEffect or call a function. It's not something special just on Next.js.

Combine that with the fact that updating cookies IS supported on server actions (like onClick on server component) I think the current behavior make sense. The only feature that currently missing, is setting cookies within client side components that run on the server. This is why I wrote the next-client-cookies package but I would really love to see native support for that from Next.js team.

[mack-useo]

@leerob - To me, setting cookies seems to be as much of a side-effect, as redirection is. But the docs say:

The redirect function allows you to redirect the user to another URL. redirect can be used in Server Components, Client Components, Route Handlers, and Server Actions.

When used in a streaming context, this will insert a meta tag to emit the redirect on the client side. Otherwise, it will serve a 307 HTTP redirect response to the caller.

(source)

So if we can redirect, why not set cookies the same way?

[luistak]

Server Components can't introduce side effects, so it's important to ensure the output remains consistent given the same input. Setting cookies is a side effect. So, to set a cookie, you must use either Server Actions, Middleware, or Route Handlers. This is my understanding.

Hum... so what is the recommended way to set a cookie in a server component?

// (some-route)/page.tsx
import { redirect } from 'next/navigation';

export default async function Page({ searchParams }) {
  const result  = await getSomeData(searchParams);

  if (result.something) {
    // How can i set a cookie here before the redirect?
    redirect('/other-page');
  }

  return <MyPageComponent />
}

@rauchg Can you elaborate on this example? using the actions and following the docs I could not find a way to do it that seemed right

[mack-useo]

To give another example - I was considering using a service that has separate session expiration and JWT expiration. When the token expires, it can be renewed with an API call as long as the session hasn't expired yet.

So the idea was:

• user visits a page that requires protected data from our API
• our API responds with 403 Unauthorized
• we make a call to renew the token
• on success we receive the renewed token
• we retry receiving the data from our API, successfully fetch the data
• the page can now be rendered, but we also need to set a cookie with the renewed token

A possible workaround is to conditionally include a client component that sets cookies on the client side, but it's a sketchy workaround and requires additional work in every component that fetches data. If we could set cookies programmatically, it would allow us to generalize the token renewal logic.

[luistak]

I thought the same thing but every way i imagine seems like a hacky workaround, it should not be so difficult to do it 😞

[BenEinwechter]

@mack-useo Like you, I have access tokens that I might need to refresh and then store in an encrypted cookie. The approach I'm planning to take is to move all token updating to middleware that happens before I even attempt an API call in a RSC. Most (all?) JWT tokens have some sort of expiration datetime stored on them, so middleware could detect access tokens that have or are about to expired, renew them, update the cookie, and then pass the request along to RSCs.

@luistak I have no idea what to do in your use case. Setting cookies before a redirect would be useful for things like transferring a flash message to the next page. Hopefully Next.js figures out a why to make RSC response act more like a normal web server response where you can change headers.

[toanil315]

@mack-useo Did you find any solution for the issued mentioned above? I encounter then same case and I'm stuck now.

[pepew-le-boss]

up

[leerob]

I've added a FAQ on this: https://nextjs.org/docs/app#how-can-i-set-cookies

You can set cookies in Server Actions or Route Handlers using the cookies function.

Since HTTP does not allow setting cookies after streaming starts, you cannot set cookies from a page or layout directly. You can also set cookies from Middleware.

[jon301]

Same issue, i'm trying to implement "flash messages" and need to be able to update cookies from Server Components:

• Submitting a form to a Server Action. The latter sets a flash message in a cookie, then redirects to the homepage
• The homepage (Server Component) reads the flash message from the cookie and renders a it, but has no way to update the cookie (to remove the flash message)

[leerob]

This repo is using flash messages with Server Actions I believe: https://github.com/Fredkiss3/gh-next

[jon301]

@leerob Thanks for the example

This repo is using flash messages with Server Actions I believe: https://github.com/Fredkiss3/gh-next

I have dug the code, unfortunately they are not using cookies but a redis storage (source, source)

I've retraced the whole flow:

• Read flash messages in a toaster Server Component (i.e. session.getFlash())
• Then, delete the flash messages and save the session
• As you can see, session is set in the redis storage and not in a cookie
• The only thing they store in a cookie is the redis session id

---

As an example, here is what i'm trying to achieve using cookies

import { cookies, headers } from 'next/headers';
import { commitSession, getSession } from '@/actions/auth';
import { parseString } from 'set-cookie-parser-es';

// Server Component
export default async function DummyPage() {
  // Retrieve encrypted session from the current request cookie
  const session = await getSession(headers().get('Cookie'));

  // Pop flash messages from the session
  const message = session.get('message') || null;

  // Compute the new `Set-Cookie` string for the response
  const commitedSession = await commitSession(session);

  // NextJS does not support writing `Set-Cookie` headers, 
  // so we need to use `cookies().set()` instead
  const { name, value, ...options } = parseString(commitedSession);
  if (name) {
    // 🚫🚫🚫🚫🚫 Error: it's not supported in Server Components 🚫🚫🚫🚫🚫
    cookies().set(name, value, options);
  }

  return (
    <main>
      // Render flash messages (could be passed to a Toaster Client Component)
      {message && <div>{message}</div>}

      // ...
    </main>
  )
}

[moshest]

If you're looking for a quick solution, this could be solved with https://www.npmjs.com/package/next-client-cookies

[rwieruch]

Opened this discussion on Lucia's GitHub, because Lucia as well showcases in their Next docs how to refresh a session cookie from a RSC lucia-auth/lucia#1540

[oh-jinsu]

For a simple way to refresh JWT on server side while respecting the FAQ.

You can set cookies in Server Actions or Route Handlers using the cookies function.
Since HTTP does not allow setting cookies after streaming starts, you cannot set cookies from a page or layout directly. You can also set cookies from Middleware.

You can manipulate serverside cookies only by Server Actions, Middleware, or Route Handlers. But at the same time you can't access your database in Middleware while it's neccessary for validating the refresh token.

So refreshing JWT should be proceeded in Route Handlers. Create a route handler that issues new access token and sets it to response cookies. In Middleware, redirect to the refresh route if the access token has expired. Pseudo code:

// middleware.ts
export async function middleware(req: NextRequest) {
  if (accessTokenHasExpired()) {
    return NextResponse.redirect(new URL(`/auth/refresh?redirectUrl=${req.url}`, req.url));
  }
}

// auth/refresh/route.ts

export async function GET(req: NextRequest) {
  const redirectUrl = new URL(req.url).searchParams.get("redirectUrl");

  const refreshToken = req.cookies.get("accessToken")?.value;

  if (!validateRefreshTokenWithDB(refreshToken)) {
    return NextResponse.redirect(new URL("/auth", req.url));
  }

  const accessToken = signAccessToken(refreshToken);

  const response = NextResponse.redirect(url);

  response.cookies.set("accessToken", accessToken, { ... });

  return response;
}

[atjsh]

Thank you for the great code. However, could you explain why you couldn't access database in Middleware? Is there a specific limitation on Middleware?

[oh-jinsu]

The middleware is designed to work in the edge runtime, so you can't use the node api.

See the following discussion about this:

#46722

But now I don't use redirections to refresh JWT like the example above. I just use 'fetch' for the refresh api on the middleware.

[ksjitendra18]

You can access database if you are using something like Drizzle ORM.

[DiiiaZoTe]

The issue here is that we have absolutely no way of refreshing a user's session during SSR...

We can validate it, refresh it in our DB, but at the end of the day we can't set the refreshed cookie directly.
A solution would be to set a client component to which we pass a boolean to tell to make an api request just to set the new cookie.

So instead of doing everything at once when you render the page, you have to:

1. render everything and send to user
2. read on the client side
3. call a fetch and go back to the server
4. on the server, re-fetch the session in the DB
5. set the new session cookie
6. send the response to the user and redirect the user if something went wrong...

This is not optimal and could easily be avoided if only we had the ability to set cookies during in RSC just like we can redirect.
Maybe make the name show that this can cause side effects and that it should only be used for specific cases.

[valourus]

I use a custom server.js file for attaching some custom logic to the nodejs side of nextjs.
I am able to set cookies on any request using the custom server.

https://nextjs.org/docs/pages/building-your-application/configuring/custom-server

   // setting the cookie on the request. This will make cookies().get('newCookie') return the cookieValue
   res.req.headers.cookie += `; newCookie=${cookieValue}`;
   // This will set the cookie on the client for future request
   res.setHeader('Set-Cookie', `newCookie=${newCookie}`);

Hopes this helps someone.

[DiiiaZoTe]

Issue is I don't want to have to do that.
Also does this mean that you set a client cookie? I would want to set a server cookie.

[valourus]

I believe cookies are always the same on the client and on the server unless you are talking about sessions.

Sessions can also be created this way but you need a place store your sessions. If you store them in memory you can no longer horizontally scale your server. You could get around by this by using something like Redis. (You should definitely do some research, this is just from the top of my head)

[DiiiaZoTe]

From what I know there still is a difference between a client cookie and a server cookie...

[sofimiazzi]

This situation with Vercel and Next.js is simply unfortunate. Although Next.js is a widely used framework, it lacks a basic method for setting cookies on server components. This absolute neglect forces developers to resort to complicated workarounds and also imposes the overhead of using middleware just to set an updated cookie.

The failure to address this fundamental issue and give it importance highlights a disconnect between developer needs and corporate priorities. It's absurd that such a glaring deficiency has persisted for so long in a framework that countless developers rely on.

[mkuchak]

I made a library to set cookies within the middleware to refresh tokens if they are out of date. This way it is possible to use updated tokens within a Server Component, for example.

https://www.npmjs.com/package/with-refresh-token

[fitimbytyqi]

@leerob Hey sir, is there any explanation to why this was closed as resolved ?

Unless this is something that cannot be implemented, I wouldn't want to be forced to use middleware or some trick with client components as mentioned above to be able to renew the cookies and instead would hope to be able to set a new cookie if response status is 401 from some server side fetch wrapper or even delete a cookie if some criteria was met.

[fitimbytyqi]

@DiiiaZoTe Im running into some issues when redirecting back to lastUrl, could you please show me the matcher object from middleware?

I don't know why when adding a manual path works and the one from the variable shows a blank page

[DiiiaZoTe]

I exclude all APIs with my matcher... but you otherwise it shouldn't be too bad to exclude on api path.

Also you may want to log the lastURL see what it contains.
Any reason why you prefer NextResponse.redirect over the redirect from Next/Navigation?

How do you set your cookie as well... if you don't set it correctly you will get undefined when retrieving the value.

[fitimbytyqi]

@DiiiaZoTe lastUrl contains the correct value that it should which means cookie has the right value,

But the issue is deeper than that, too hard to explain but ill try in shorter terms.

1. User clicks on second page of the users list (lets suppose access_token has expired at this time).
2. /en/users?page=2 is saved in the cookie under x-last-url
3. fetch wrapper catches error 401 and calls api/refresh-token route handler
4. route handler sets the new cookie with the new access_token
5. route handler redirects the user to x-last-url
6. here I usually get a blank page (even if my url in the search bar is /en/users?page=2)

If I manually make the x-last-url to point to /en/users?page=2 and I lets say the route handler executes when I go on page=3
In this case, whenever I press page=3 it's going to always redirect to page=2 for some unknown reasons (it's too weird because only going to page=3 does that and other pagination items don't).

I might go back to handle refresh token on middleware and see if that works out for me.

[DiiiaZoTe]

Yeah it's too hard for me to say without actually looking at the code... If you have the correct value in lastURL and redirection works for other paths, then it should for the last url as well. Unless there is an issue somewhere else in your logic that isn't related to this specific redirect.

[fitimbytyqi]

Yeah, Im planning to test it out in a project from scratch tomorrow just In case some other part is intercepting with the logic.

Hopefully i'll get to find a solution because Im running out of ideas and time and energy and everything.