You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 9cbd650
Browse filesBrowse the repository at this point in the historyBrowse files
feat(shared,ui): pass the reverification result to the retried request
A password change retried after reverification failed or overwrote the
password the user had just reset: custom flows send the old
`currentPassword`, and the modal could save a different password than
the form's.
`useReverification()` takes a `passReverificationResult` option. With
it, the wrapped function receives the reverification result as its
first argument (`undefined` on the first call). After a reset by code,
`passwordReset` holds the new password and the sign out choice, so the
retry can skip `updatePassword()`. UserProfile's PasswordForm uses it
in place of `resetPassword.onPasswordChange`, which is removed.
The modal records the reset attempt at the UserVerification routes
level, so the result is still available when verification completes
on the second factor.
If an older clerk-js rejects the reset password code strategy, the code
screen now shows the error instead of waiting for a code that was never
sent.
Copy file name to clipboardExpand all lines: .changeset/reverification-reset-breached-password.md
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,3 +9,14 @@ Let users whose password was found in a data breach pass reverification by reset
9
9
From UserProfile's change password form, the modal reuses the new password the user already entered, so they only enter the code.
10
10
11
11
`session.prepareFirstFactorVerification()` and `session.attemptFirstFactorVerification()` accept the `reset_password_email_code` and `reset_password_phone_code` strategies, so custom flows can build the same reset.
12
+
13
+
`useReverification()` accepts a new `passReverificationResult` option. With it, the fetcher receives what the reverification did as its first argument: `passwordReset` holds the new password and sign out choice when the user reset their password in the modal. Custom password change flows should adopt it: after the user resets their password to reverify, retrying `user.updatePassword()` would fail on the old `currentPassword` or overwrite the password the user just set.
0 commit comments