app/api/set-session-cookie/route.ts

import { NextRequest, NextResponse } from "next/server";
import { setSessionTokenCookie } from "@/lib/auth/session";

export async function POST(request: NextRequest) {
  const { token, expiresAt } = await request.json();
  return setSessionTokenCookie(token, new Date(expiresAt));
}

Thanks for your help, and please note that I've been coding for only a month so if you want to yell at me for something go ahead.

when you put "use server" on your signup action, that hoists it to the server, so from there you don't actually need to make a fetch POST to your API route, you should be able to call that api like a function

I suspect it's this second request you're doing where the cookie is getting lost

@Mallow bee so remove the fetch completely and embed the function directly?

copy this bit into the signup action directly, and if that works and you'd still prefer it to be in a separate function then you can replace it with a function call

const cookieStore = await cookies();
  console.log("Setting cookie with token:", token);
  console.log("Cookie expires at:", expiresAt);

  cookieStore.set("session", token, {
    httpOnly: true,
    path: "/",
    secure: process.env.NODE_ENV === "production",
    sameSite: "strict",
    expires: expiresAt,
  });

my debugging strategy here is to just remove as many hops that the code has to do as possible, until you have the simplest input/output that's easy to make sense of

Thanks mate, I'll try now.

basically when you call fetch() yourself, you're making a new request, and I'm not sure if Next's cookies() and related functions are meant to be smart enough to pass everything back to the original request. I don't think they should be able to, since you might be calling a third party

This is my complete signup action, which doesn't show the cookie on the client:

"use server";

import { generateSessionToken, createSession } from "@/lib/auth/session";
import { createUser } from "@/lib/auth/user";
import {
  emailSchema,
  passwordSchema,
  usernameSchema,
} from "@/utils/validation";
import { cookies } from "next/headers";
import { z } from "zod";

export default async function signup(_: any, formData: FormData) {
  const username = formData.get("username");
  const email = formData.get("email");
  const password = formData.get("password");

  if (
    typeof email !== "string" ||
    typeof username !== "string" ||
    typeof password !== "string"
  ) {
    return {
      message: "Invalid or missing fields",
    };
  }

  try {
    usernameSchema.parse(username);
    emailSchema.parse(email);
    passwordSchema.parse(password);
  } catch (error) {
    if (error instanceof z.ZodError) {
      return {
        message: "Server validation failed",
        error: error.errors[0].message,
      };
    }
    return {
      message: "An unexpected error occurred",
    };
  }

  const user = await createUser(username, email, password);

  const token = await generateSessionToken();
  const session = await createSession(token, user.id);

  const cookieStore = await cookies();
  console.log("Setting cookie with token:", token);
  console.log("Cookie expires at:", session.expiresAt);

  cookieStore.set("session", token, {
    httpOnly: true,
    path: "/",
    secure: process.env.NODE_ENV === "production",
    sameSite: "strict",
    expires: session.expiresAt,
  });

  return {
    message: "Signup successful",
  };
}

can you see that POST request happening in your network tab?

you should see a Set-Cookie header, and if Chrome (not sure about other browsers) doesn't want to accept it it'll have a little warning beside it

This?

I'd expect a POST request

if you clear your network list and then click the signup button you should see it in the new requests

Sorry, but how to clear it?

Nvm, did it.

top left, the slashed circle

then try the action, hopefully you see a POST request there

and then you'll be looking at Response Headers to see if there's a Set-Cookie header

This seems a bit odd...

that could mean the request never completes

could be any of your awaits hanging

Oh in my headers I have:

the Set-Cookie

ok so it's keep-alive, which means it's a stream, and that's why you don't see anything in the response

under Expires I'm seeing 21 jan 1970

which I suspect is exactly 1000 times closer to Jan 1 than it is to the current date

maybe you set an expires time in seconds instead of milliseconds?

Here is the session logic that may be causing it:

"use server";

import bcrypt from "bcryptjs";
import crypto from "crypto";
import redis from "../db/redis";
import { NextResponse } from "next/server";
import { cookies } from "next/headers";

export async function setSessionTokenCookie(token: string, expiresAt: Date) {
  const cookieStore = await cookies();
  console.log("Setting cookie with token:", token);
  console.log("Cookie expires at:", expiresAt);

  cookieStore.set("session", token, {
    httpOnly: true,
    path: "/",
    secure: process.env.NODE_ENV === "production",
    sameSite: "strict",
    expires: expiresAt,
  });

  return new NextResponse(
    JSON.stringify({ message: "Session cookie set successfully!" }),
    {
      status: 200,
    }
  );
}

export async function generateSessionToken() {
  const token = crypto.randomBytes(32).toString("hex");
  return token;
}

export async function createSession(token: string, userId: string) {
  const sessionId = await bcrypt.hash(token, 12);
  const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60 * 24 * 30;
  const session = {
    id: sessionId,
    userId,
    expiresAt,
  };

  await redis.hmset(`session:${session.id}`, {
    id: session.id,
    userId: session.userId,
    expiresAt: session.expiresAt,
  });
  await redis.expireat(`session:${session.id}`, session.expiresAt);
  await redis.sadd(`user_sessions:${userId}`, session.id);

  return session;
}

try expires: expiresAt * 1000

or rather in your createSession, don't divide by 1000

I guess if you've been doing that already you might want to keep it compatible, so you get to make a choice there

Sorry for the wait, but now I'm getting:

session=a58443a8bee146d96e1e30a89376d65794d29ef8541e5c4f079e9ebe68345e49; Path=/; Expires=Tue, 25 Mar 2025 06:14:11 GMT; HttpOnly; SameSite=strict

is that about right?

yeah that looks like the right date, should last for a month

can't tell at a glance if the session ID is right but this one should at least get set in the browser

you can check in dev tools -> application -> cookies to see if it's there

think you need to expand the cookies dropdown

that UI kinda sucks, it should show an index of the sites instead of just learn more

Cookie expires at: 1742883545156

was logged in the console, I believe it's still the time complications.

Which is logged here:

const user = await createUser(username, email, password);

  const token = await generateSessionToken();
  const session = await createSession(token, user.id);

  const cookieStore = await cookies();
  console.log("Setting cookie with token:", token);
  console.log("Cookie expires at:", session.expiresAt);

nope that sounds right

Also, thanks for your help I really appreciate it.

Yeah it is in the dropdown, thanks.

This is correct right?

yeah looks right to me

Alright, tysm for your help @Mallow bee , true legend mate.

biggest recommendation here is to just get familiar with using the network tab when debugging this, since there's so many places for things to go wrong

the set-cookie header is the ONLY way the browser can set an HttpOnly cookie

so first thing to check is if that exists, and if the browser accepts it. You'll see right next to the header if the browser rejects it because the domain or path is wrong, for example

any expiresAt in the past will be deleted immediately, setting expires to past values is actually the only way to delete a cookie too

Yeah, I suppose I'm rushing a little bit but I just want to develop a SaaS in the long run. Thanks for your help again though!

seeing a date in the middle of january 1970 is almost always a seconds vs milliseconds issue, that one just comes from having seen it before

and then once you can see the cookie is set properly, the second half of debugging is about making sure the cookie gets sent out on your next requests and that the server can read them