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?

[gaburielcasado]

@mack-useo makes a very good point and I wish we'd at least get an answer to that. Even if it's just "we don't want to set cookies the same way because we don't want to set cookies the same way". It's frustrating to rely on janky workarounds without even knowing if a decent way of setting httponly cookies on server components will ever be released.

[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

[PoSayDone]

You are my savior, for weeks I have been looking for ways to solve my authorization problem and your library -- this is exactly what I was looking for. Thank you so much.

[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.

[pepew-le-boss]

Is it possible to set a cookie from a RSC via a Route Handler ?
Knowing that we can't directly from the RSC but we can from a Route Handler I've tried but it doesn't seem to work.

// this function is called at the top of multiple RSC in my app
export async function handleGetCart() {
  // some logic ...
  if (cart.tokenValue) {
    const res = await fetch(`${process.env.NEXT_PUBLIC_WEBSITE_URL}/api/cart-token`, {
      method: "POST",
      body: JSON.stringify({ cartToken: cart.tokenValue }),
    })
    console.log(res.headers)
    console.log(cookies().getAll())
  }
  // some more logic ..
}

// /api/cart-token/route.ts
export async function POST(request: NextRequest) {
  const req = await request.json()
  const cartToken = req.cartToken
  cookies().set("cartToken", cartToken)
  return new Response("test", {
    status: 200,
    // headers: {
    //   "Set-Cookie": `cartToken=${cartToken}`,
    // },
  })
}

I've tried with the cookies().set() method and also with the Set-Cookie header but the response is the same. I can see the cookie in the response HeadersList object:
cookies: [ 'cartToken=123456; Path=/' ]
'set-cookie' => { name: 'set-cookie', value: 'cartToken=123456; Path=/' },

The problem is that I don't have the cartToken inside cookies().getAll() neither in the application tab of the browser

[DiiiaZoTe]

I don't believe so since the route handler is called within the RSC, I believe it will be part of the same unit of work. So when the RCS renders the response won't allow cookies to be set.
Correct me if I'm wrong...

[pepew-le-boss]

Yeah I think that's the case. That seemed very hacky anyway. I will change the way I do things and use the middleware

[DiiiaZoTe]

That's the whole point of this Github discussion... It is "closed", yet it's an unresolved issue for a lot of devs.
There are lots of cases where one could make use of the ability to set cookies in RSC, but seems like their mind is set.

[marcelovicentegc]

One way to overcome this issue, and which I've found to be the most convenient method (validated on production environments), is to:

1. Create a server action which changes httpOnly cookies
2. Create a client component that receives this action as prop
3. Automatically trigger the server action upon rendering

"use client";

import { useEffect, useRef } from "react";

interface Props {
  someServerAction: () => Promise<void>;
}

export function SetHttpOnlyCookies(props: Props) {
  const { someServerAction } = props;
  const ref = useRef<HTMLInputElement>(null);

  useEffect(() => {
    ref.current?.click();
  }, []);

  return (
    <input
      type="hidden"
      value={locale}
      ref={ref}
      onClick={someServerAction}
    />
  );
}

On some server component, just import and render the component:

const serverAction = async () => {
   // Set cookies; do whatever
}

<SetHttpOnlyCookies someServerAction={serverAction} />

[errnesto]

I like the idea of a generateHeaders as proposed here: #58110 I would also be happy with a generateCookies helper if all of the headers is too much… But there has also been no update about this for a while now…

[Pedromigacz]

This and the middleware issue make pages router attractive again

[braska]

This is not an issue neither a bug. It is consequence of using streaming (during rendering). It is fundamental limitation of web technologies (HTTP protocol). It is not a Next.js fault.

Fundamental limitation of HTTP streaming: once response headers are served and you started streaming of body of the response, you can't send additional headers. So all headers should be sent before serving response body (with HTML in it, if we talking about server-side rendering).

Using streaming is a conscious choice - this is the way to do SSR (and websites in general) in 2024, because we value speed and performance.

In order to make it work the way you (and a lot of people in this thread) want, it would require ditch an idea of streaming. That would mean that Next.js would have to render a whole page before start responding to user. And as result response time of all your pages will be much higher. And also all new React features like Server Components (they are fully based on streaming in order to allow use them with Suspense), and Partial Prerendering (introduced in Next.js 15) will be unavailable to you.

[Pedromigacz]

Yes, I understand that once streaming starts, you can't set a header/cookie, because that's how http and browsers works.
But a solution that's been discussed right now is to add a page level middleware, which would let us run code before the streaming process start and allow us to set cookies/headers per page request.
One of the most common ways to handle auth (with sessions) is just a lot harder then needed because of this. And I've seen a lot of security issues arise from the hackish ways some projects are trying work around it.
It's not unreasonable to ask for a way to set cookies and headers per page.

[braska]

Ah, I see. Having improved DX with middlewares (define them per route) is a valid point.

I am just commenting based on this discussion title: "Add set method to cookies function in Server Components". And I think we both agree with the answer to that - it is not possible and never will be.

Regarding middleware: is there anything that prevents you to use it now to achieve desired behavior? Or is it just the DX issue (you have to put a bunch of ifs to detect a route)?

[Pedromigacz]

I get you, you are right. This is not the proper discussion to say what I've said. And this exactly behavior would go against the whole framework.

1. Yes, I can't, in example, access my db on edge, and even if I could it would be terribly slow to do so.
   My use case is that we need to handle sessions on a middleware, and our work around for the time being involves dealing with route handlers, redirects and server side HOC. It's slower for our final users and has an unnecessary complexity to it. The equivalent in middlewares takes around 10 lines of reusable code and is a lot more performatic.
2. Additionally, we want to run next on a server environment, I can't do that using next default middleware.

[braska]

1. I see. That's partially valid. Middleware runtime is limited. But if you could somehow make all required cookie-related work there, that would solve your problem. I still convinced it is possible. For example, in my case I managed to use Apollo GraphQL client in middleware (that's different story, but I think it shows that middleware runtime is capable in doing pretty complex things).
2. That's not true. Middlewares can be run on servers (self-hosted). See: https://nextjs.org/docs/app/building-your-application/deploying#middleware

[achandansoni]

Hey guys, so my problem is that I have a method which calls an api from server and this api sets some cookie how i can forward this cookie to browser I believe this feature should be there in any framework claiming to be capable for ssr. but as in next js we can set cookie from #1 server action which means i need to trigger my method from client and #2 I need to make a route handler which means i need to call this also from client side. where is ssr in this method. if there is any other please let me know @leerob.

[soheil-jafari-nextjs]

any update about this problem?
i can't set any cookie in route handler or server action from server component....

[Nader-CS]

same