Skip to content

feat(console): add AUTH_COOKIE_DOMAIN to scope the Firebase auth cookie#1349

Open
vklimontovich wants to merge 4 commits into
newjitsufrom
feat/auth-cookie-domain
Open

feat(console): add AUTH_COOKIE_DOMAIN to scope the Firebase auth cookie#1349
vklimontovich wants to merge 4 commits into
newjitsufrom
feat/auth-cookie-domain

Conversation

@vklimontovich
Copy link
Copy Markdown
Contributor

What

The jitsu-auth Firebase session cookie is set with domain = getRequestHost(req) — i.e. host-only (use.jitsu.com). Sibling subdomains on the same apex (e.g. a marketing site at jitsu.com) therefore never receive it and can't read the logged-in session server-side.

This adds an optional AUTH_COOKIE_DOMAIN env var. When set (e.g. jitsu.com), the auth cookie is scoped to that parent domain and is shared across its subdomains. Unset preserves the current host-only behaviour.

Why

So a separate app on a sibling subdomain can resolve the logged-in user from the cookie (verify the session-cookie JWT) and, for example, attach identity to analytics — without a cross-origin /api/me round-trip.

Changes

  • serverEnv.ts — add optional AUTH_COOKIE_DOMAIN.
  • firebase-server.tsgetAuthCookieDomain(req) helper: AUTH_COOKIE_DOMAIN if set, else the request host.
  • create-session.ts — set the cookie with that domain.
  • revoke-session.ts — clear the cookie with the same domain (otherwise a domain-scoped cookie won't be cleared on logout).

Notes

  • Default behaviour is unchanged when the var is unset.
  • Security: widening to a parent domain shares the session across all its subdomains — only set it on a domain you fully control.

The jitsu-auth session cookie is scoped to the request host, so sibling
subdomains (e.g. a marketing site on the apex domain) can't read the logged-in
session. Add an optional AUTH_COOKIE_DOMAIN env var to widen the cookie to a
parent domain; unset keeps the current host-only behaviour. Applied to both the
set (create-session) and clear (revoke-session) paths so logout still works.
jitsu-code-review[bot]
jitsu-code-review Bot previously approved these changes Jun 5, 2026
Copy link
Copy Markdown

@jitsu-code-review jitsu-code-review Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed auth-cookie domain changes across firebase session create/revoke handlers and server env wiring. I found a couple of correctness issues around cookie scoping/clearing and left inline comments with concrete fixes.

const domain = getRequestHost(req).split(":")[0];
// Host-only by default; AUTH_COOKIE_DOMAIN can widen it to a parent domain
// so sibling subdomains share the session.
const domain = getAuthCookieDomain(req);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential correctness issue: this path is described as "host-only by default", but we always send a domain attribute (domain is always set in options). Per cookie semantics, host-only cookies require omitting Domain entirely. As written, default behavior is a domain cookie for the current host (and can include subdomains). If host-only is intended, can we make domain optional and only set it when AUTH_COOKIE_DOMAIN is configured?

httpOnly: true,
secure,
// Must match the domain used when the cookie was set, or it won't clear.
domain: getAuthCookieDomain(req),
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possible logout bug: delete uses matching domain now, but it still omits path: "/". The session cookie is created with path: "/" in create-session.ts; clearing with a different/default path may fail to remove the real auth cookie. Can we set path: "/" here too so name+domain+path all match?

Address review on #1349:
- omit the Domain attribute unless AUTH_COOKIE_DOMAIN is set (a true host-only
  cookie must not send Domain), so getAuthCookieDomain returns string | undefined
- clear the cookie with path "/" in revoke-session so name+path+domain all match
  create-session and logout actually removes it
jitsu-code-review[bot]
jitsu-code-review Bot previously approved these changes Jun 5, 2026
Copy link
Copy Markdown

@jitsu-code-review jitsu-code-review Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the auth-cookie domain changes across create-session, revoke-session, and server env wiring. The domain/path matching logic now looks consistent for set/clear. I left two inline comments for follow-up: one security concern (session token value logged) and one correctness/maintainability issue (duplicate AUTH_COOKIE_DOMAIN schema key).

const domain = getAuthCookieDomain();
getLog()
.atDebug()
.log(`Setting firebase auth cookie (domain: ${domain ?? "host-only"}): ${cookie}`);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential security issue: this debug statement logs the full Firebase session cookie value (${cookie}), which is a bearer credential. If debug logs are enabled or exported, this can leak active sessions. Can we avoid logging the raw token and log only non-sensitive metadata instead?

Comment thread webapps/console/lib/server/serverEnv.ts Outdated
// request host (e.g. "use.jitsu.com"). Set this to a parent domain (e.g.
// "jitsu.com") to share the session across sibling subdomains — for example so a
// marketing site can read the logged-in user. Leave unset for host-only scope.
AUTH_COOKIE_DOMAIN: z.string().optional(),
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AUTH_COOKIE_DOMAIN is already declared earlier in the same schema (line 112). Duplicating object keys means the later entry silently overrides the earlier one, which can cause comment/schema drift. Can we keep a single declaration and one canonical description?

AUTH_COOKIE_DOMAIN is already declared in serverEnv.ts (used by nextauth);
this PR only needs to wire it into the firebase auth cookie. Remove the
duplicate that broke the build (TS1117).
jitsu-code-review[bot]
jitsu-code-review Bot previously approved these changes Jun 5, 2026
Copy link
Copy Markdown

@jitsu-code-review jitsu-code-review Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the Firebase auth cookie domain/path updates and logout clearing behavior. I found one security issue to address (inline): session cookie value is logged in plaintext.

const domain = getAuthCookieDomain();
getLog()
.atDebug()
.log(`Setting firebase auth cookie (domain: ${domain ?? "host-only"}): ${cookie}`);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Security issue: this logs the full Firebase session cookie token ($cookie), which is a bearer credential. Even in debug level, this can leak active sessions via log aggregation or support dumps. Can we remove the token from logs and keep only non-sensitive metadata (e.g., domain + expiry)?

The debug statement logged the full session-cookie value, a bearer
credential that could leak active sessions via log aggregation. Log
only non-sensitive metadata (domain + expiry) and use the file's named
logger.
Copy link
Copy Markdown

@jitsu-code-review jitsu-code-review Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the Firebase auth cookie changes in:\n- webapps/console/lib/server/firebase-server.ts\n- webapps/console/pages/api/fb-auth/create-session.ts\n- webapps/console/pages/api/fb-auth/revoke-session.ts\n\nChecked cookie domain/path matching on set+clear, host-only behavior when is unset, and token logging safety. I did not find new actionable correctness or security issues in this diff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant