Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Multi-session: getToken() on a non-active session writes that session's token into __session

Aperta
  • Qualcosa non va?
#9,972 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
authentication

Direzione di ricerca

Start in packages/clerk-js/src/core/resources/Session.ts at #hydrateCache and getToken(), then trace TokenUpdate handling in packages/clerk-js/src/core/auth/AuthCookieService.ts. Verify the active-session check against the described multi-session flow. Done means getToken() and hydration for an inactive session still return its token without updating __session, while the active session continues to update the cookie.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Preliminary checks
Reproduction

Found by reading the source. There is no public repro repo yet. The steps below reproduce it in any multi-session app.

  1. Turn on multi-session. Sign in as user A, then add user B in the same browser, so one client holds 2 sessions. A is the active session in the tab.
  2. In the focused tab, call getToken() on B's session object, for example clerk.client.sessions.find(s => s.id !== clerk.session.id).getToken(). A common reason is to call your own API as B, for example to list B's data in an account switcher.
  3. Read the __session cookie. It now holds B's token. The next request from this tab to the app's server is authenticated as B, although the tab still shows A.
  4. Keep the tab focused. B's token refreshes in the background about every 43 s, and each refresh writes __session again. The tab's own poller writes A's token back within about 1.5 s. So the server sees B for short windows, over and over.
Publishable key

Can share privately on request.

Description

In @clerk/[email protected], Session.getToken() decides whether to emit TokenUpdate like this:

https://github.com/clerk/javascript/blob/%40clerk/clerk-js%406.34.1/packages/clerk-js/src/core/resources/Session.ts#L459

const shouldDispatchTokenUpdate = !template && organizationId === this.lastActiveOrganizationId;

It does not check whether this is the client's active session. AuthCookieService writes every TokenUpdate into __session while the tab has focus:

https://github.com/clerk/javascript/blob/%40clerk/clerk-js%406.34.1/packages/clerk-js/src/core/auth/AuthCookieService.ts#L79-L82

The background-tab guard in updateSessionCookie (L202-L207) does not help here, because the tab that calls getToken() is the focused one.

#hydrateCache has the same gap. It sets shouldDispatchTokenUpdate = true for any session that it hydrates, so a non-active session whose last token still has more than about 17 s left gets a focused refresh that writes __session:

https://github.com/clerk/javascript/blob/%40clerk/clerk-js%406.34.1/packages/clerk-js/src/core/resources/Session.ts#L217-L229

The code at main (2ee976bb66, 2026-09-28) is the same.

Expected: only the client's active session writes __session. getToken() on any other session returns a token and does not touch the cookie.

Actual: the cookie flips to the other user. In production, the server then sees user B for requests the user makes as A. For us that showed up as brief authorization refusals on pages that A may open. If both users belong to the same organization, a write could be attributed to the wrong user.

Suggested fix: also require this.id === <client's active session id> in both places, at L221 and L459. A JWT template token already skips the event, but templates cannot carry sid, so they are not a replacement for servers that check session revocation.

We are working around this by listing the other accounts' data on our server, and no longer calling getToken() on inactive sessions in the browser.

Environment
@clerk/clerk-js: 6.34.1 (loaded from the Clerk CDN via @clerk/shared 4.31.0)
@clerk/nextjs: current
Framework: Next.js (App Router)
Browsers: Chrome, Arc, Safari on macOS
Multi-session: enabled
Lingua principale
TypeScript
Stelle
1.8k
Fork
477
Merge medio
2g 25m
PR unite (30g)
267

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di clerk/javascript

Tutte le issue di clerk/javascript

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.