Multi-session: getToken() on a non-active session writes that session's token into __session
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 72/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
Preliminary checks
- I have reviewed the documentation: https://clerk.com/docs
- I have searched for existing issues: https://github.com/clerk/javascript/issues
- This issue is not a question, general help request, or feature request.
Reproduction
Found by reading the source. There is no public repro repo yet. The steps below reproduce it in any multi-session app.
- 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.
- In the focused tab, call
getToken()on B's session object, for exampleclerk.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. - Read the
__sessioncookie. 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. - Keep the tab focused. B's token refreshes in the background about every 43 s, and each refresh writes
__sessionagain. 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:
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:
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:
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
- 主要语言
- TypeScript
- 星标
- 1.8k
- 派生
- 477
- 平均合并
- 1 天 18 小时
- 30 天内合并 PR
- 287
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
clerk/javascript 的其他 Issue
-
signIn.sso() ignores oidcPrompt for OAuth strategies可能已有人在做 @wobsoriano 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
clerk/javascript#10119 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
clerk/javascript#10026 · 1 条评论 ·
维护者通常 1 天内回复
-
@clerk/nextjs: onBeforeSetActive never settles when invalidateCacheAction rejects (e.g. after a redeploy), so setActive and signOut hang forever可能已有人在做 @RaphaelFakhri 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
clerk/javascript#9987 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 1-2 天 新手友好度 45/100
clerk/javascript#10118 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
clerk/javascript#10117 ·
维护者通常 1 天内回复
相似的 Issue
-
component:sight
难度 2/5 1-3 小时 新手友好度 78/100
agentic-os-org/ANOLISA#6738 · 2 条评论 ·
维护者通常 1 天内回复
-
bug Durable Agents Observability (AI Telemetry) status: needs triage
难度 2/5 1-3 小时 新手友好度 82/100
mastra-ai/mastra#26470 · 1 条评论 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 76/100
paperclipai/paperclip#15630 ·
维护者通常 1 天内回复
-
[good first issue, hacktoberfest] ⛩️ Add new Theme: Sakura Latte (good-first-issue)可能已有人在做 @PGrayCS 今天认领。 未关闭community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
难度 1/5 1-3 小时 新手友好度 78/100
lingdojo/kana-dojo#31937 · 1 条评论 · 5 个 reaction ·
维护者通常 1 天内回复
-
feature/cohorts feature/feature-flags team/feature-flags
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复