Make the session cookie name configurable for a staging deployment
Groundwork for testmodul.qrmaster.net, a second stack running the `test` branch on a real qrmaster.net subdomain. Production scopes its session cookie to .qrmaster.net, so the browser sends it to every subdomain including staging. With both environments naming the cookie `userId`, the browser holds two cookies of the same name and cookies.get() picks one arbitrarily - staging logins would look randomly signed-out. AUTH_COOKIE_NAME lets staging pick `userId_test` instead. Production keeps the `userId` default; changing it there would invalidate every existing session. Wired getAuthCookieName() into the six places that named the cookie literally. The account deletion route now expires both the host-only and the domain-scoped variant like the logout route already does, instead of a single cookies().delete() that would leave the other one behind. NEXT_PUBLIC_WWW_URL and NEXT_PUBLIC_APP_URL become build ARGs so the same image can be built pointing at the staging host - the defaults keep a plain production build byte identical to before. Like COOKIE_DOMAIN these must exist at build time, because process.env is inlined into the Edge middleware bundle. robots.ts now serves Disallow-all unless NEXT_PUBLIC_INDEXABLE is true. Staging otherwise returns the production robots.txt and invites crawlers to index a duplicate of www. docker-compose.test.yml is the staging overlay. Two things it must get right, both verified against `docker compose config`: - db and redis need `networks: !override`. Compose MERGES the networks mapping from the base file, and since qrmaster-network is external and shared, a plain list left them attached to it - `db` would then resolve to two containers and staging could read and write the production database. - The web entrypoint is replaced so `prisma migrate deploy` never runs. prisma/migrations stopped in April 2026 and the schema has moved on through manual SQL since, so applying them to a fresh database would build a stale schema. Staging gets its schema from `pg_dump --schema-only` against production instead. Verified: tsc clean, production build succeeds, and the merged compose config confirms staging keeps db/redis off the shared network while production resolves unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -26,6 +26,21 @@ export function getCookieDomain(): string | undefined {
|
||||
return domain ? domain : undefined;
|
||||
}
|
||||
|
||||
/**
|
||||
* Name of the session cookie.
|
||||
*
|
||||
* Configurable so a staging deployment on another qrmaster.net subdomain can pick a
|
||||
* distinct name. Production scopes its cookie to `.qrmaster.net`, so the browser sends it
|
||||
* to testmodul.qrmaster.net as well; two cookies with the same name would make
|
||||
* `cookies.get()` ambiguous and staging logins flaky.
|
||||
*
|
||||
* Like COOKIE_DOMAIN this must be set at build time too, because process.env is inlined
|
||||
* into the Edge middleware bundle.
|
||||
*/
|
||||
export function getAuthCookieName(): string {
|
||||
return process.env.AUTH_COOKIE_NAME?.trim() || 'userId';
|
||||
}
|
||||
|
||||
/**
|
||||
* Get cookie options for authentication cookies
|
||||
*/
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
import 'server-only';
|
||||
import crypto from 'crypto';
|
||||
import { cookies } from 'next/headers';
|
||||
import { getAuthCookieOptions } from './cookieConfig';
|
||||
import { getAuthCookieName, getAuthCookieOptions } from './cookieConfig';
|
||||
|
||||
/**
|
||||
* Signed session cookie.
|
||||
@@ -11,8 +11,6 @@ import { getAuthCookieOptions } from './cookieConfig';
|
||||
* detect a tampered/forged cookie and reject it. Format: `<userId>.<signature>`.
|
||||
*/
|
||||
|
||||
export const AUTH_COOKIE_NAME = 'userId';
|
||||
|
||||
function getSecret(): string {
|
||||
const secret = process.env.NEXTAUTH_SECRET;
|
||||
if (!secret) {
|
||||
@@ -68,12 +66,12 @@ export function verifySignedUserId(value: string | undefined | null): string | n
|
||||
* Use this in route handlers instead of reading the `userId` cookie directly.
|
||||
*/
|
||||
export function getSessionUserId(): string | null {
|
||||
return verifySignedUserId(cookies().get(AUTH_COOKIE_NAME)?.value);
|
||||
return verifySignedUserId(cookies().get(getAuthCookieName())?.value);
|
||||
}
|
||||
|
||||
/**
|
||||
* Set the signed auth cookie for the given user id (server component / route handler context).
|
||||
*/
|
||||
export function setSessionCookie(userId: string): void {
|
||||
cookies().set(AUTH_COOKIE_NAME, signUserId(userId), getAuthCookieOptions());
|
||||
cookies().set(getAuthCookieName(), signUserId(userId), getAuthCookieOptions());
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user