Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#9,287 4 Kommentare 2 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
50/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
react, typescript
Bereich
authentication, frontend

Rechercherichtung

Beginne mit dem vorgefertigten @clerk/react -Flow und dem Übergang von needs_second_factor nach erfolgreicher Passwortauthentifizierung. Verfolge, wo prepareSecondFactor() aufgerufen wird, und vergleiche dies mit der im Backend vorbereiteten Verifizierung, die in den Dashboard-Ereignissen angezeigt wird. Reproduziere dies mit password plus email_code MFA und bestätige anschließend, dass nur ein explizites Resend einen weiteren Code sendet.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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)
Vorherrschende Sprache
TypeScript
Sterne
1.8k
Forks
479
Ø Merge
1 T. 21 Std.
Gemergte PRs (30 T.)
308

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus clerk/javascript

Alle Issues in clerk/javascript

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.