Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[@clerk/react v6] <SignIn> sends duplicate email_code on second-factor (MFA) step, distinct from #8463

未关闭
  • 哪里不对？
#9,287 4 条评论 2 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
50/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
react, typescript
领域
authentication, frontend

调研方向

从预构建的 @clerk/react 流程开始，跟踪密码验证成功后从 needs_second_factor 开始的转换。跟踪 prepareSecondFactor() 的调用位置，并将其与 dashboard 事件中显示的由后端准备的验证进行比较。使用 password plus email_code MFA 重现，然后确认只有显式的 Resend 才会发送另一个代码。

由索引模型根据 Issue 内容生成。

描述

Reproduction
  1. Instance has password as first factor, email_code as the (only) required second factor / MFA strategy.
  2. Render prebuilt <SignIn routing="path" path="/sign-in" signUpUrl="/sign-up" /> (no custom flow).
  3. Submit correct password. First factor passes cleanly (no duplicate here).
  4. Sign-in transitions to needs_second_factor. Two email_code verification emails arrive ~1 second apart; the first code is invalidated by the second.
Dashboard log evidence (single sign_in_id, single client)
sign_in.attempt_first_factor.passed       strategy=password         (T+0.0s)
sign_in.email_address.verification_code_sent                        (T+0.0s)  <- code #1
sign_in.prepare_second_factor.passed      strategy=email_code, new verification_id (T+0.0s)
sign_in.email_address.verification_code_sent                        (T+1.0s)  <- code #2, invalidates #1

Same sign_in_id, same client_id, same IP across all four events — this is one browser tab, one attempt, not a remount/refresh or a second tab.

Why this looks like a sibling of #8463, not a duplicate report

#8463 (closed, "fixed in Core 3") and #8684/#4324 are about prepareFirstFactor / SignUp.create() re-sending a code on remount or because create() already prepares under the hood before an explicit prepare call fires again.

This reproduces on @clerk/[email protected] (Core 3, current latest), with no remount involved — it's the transition from first-factor success straight into the second-factor (MFA) step, in a single mount. It looks like the same class of bug (backend/widget both send a code for the same verification step) but on the prepareSecondFactor code path specifically, which doesn't appear to have been covered by the Core 3 fix for the first-factor case.

Expected behavior

When a sign-in transitions to needs_second_factor and email_code is the strategy, <SignIn> should resume on whatever verification the backend already prepared for that transition (if any) rather than unconditionally calling prepareSecondFactor() again. A second code should only be sent when the user explicitly clicks "Resend."

Environment
  • @clerk/react: 6.12.9
  • React: 19, Vite 6
  • pk_test_* instance, password + email_code (as second factor/MFA) enabled
  • Reproduces in Chrome (desktop), consistently, every sign-in attempt requiring the second factor
Related
  • #8463 (first-factor/remount case, closed as fixed in Core 3 — this is a different code path)
  • #8684, #4324 (SignUp / prepareFirstFactor variants of the same "double prepare" pattern)
主要语言
TypeScript
星标
1.8k
派生
477
平均合并
2 天 25 分钟
30 天内合并 PR
267

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

clerk/javascript 的其他 Issue

查看 clerk/javascript 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。