Releases: clerk/javascript
Release list
@clerk/testing@2.2.5
@clerk/tanstack-react-start@1.4.15
@clerk/shared@4.25.1
Patch Changes
- Deprecate
createPathMatcher()and its pattern types (PathMatcherParam,PathPattern,WithPathSegmentWildcard). Pattern-based path matching is being phased out along with the framework-levelcreateRouteMatcher()helpers and will be removed in the next major version. Use your framework's native routing primitives to decide which paths to protect instead. (#9094) by @jacekradko
@clerk/react-router@3.5.7
@clerk/nextjs@7.5.15
@clerk/vue@2.4.12
@clerk/ui@1.25.0
Minor Changes
-
Add support for Clerk Protect mid-flow SDK challenges (
protect_check) on both sign-up and sign-in. (#8329) by @zourzouvillysWhen the Protect antifraud service issues a challenge, responses now carry a
protectCheckfield
with{ status, token, sdkUrl, expiresAt?, uiHints? }. Clients resolve the gate by loading the
SDK atsdkUrl, executing the challenge, and submitting the resulting proof token via
signUp.submitProtectCheck({ proofToken })orsignIn.submitProtectCheck({ proofToken }). The
response may carry a chained challenge, which the SDK resolves iteratively.Sign-in adds a new
'needs_protect_check'value to theSignInStatusunion. Upgrading this
package is type-only and does not change runtime behavior: the server returns the new status
(and theprotectCheckfield) only for instances where Protect mid-flow challenges have been
explicitly enabled — the feature is off by default and is not enabled for existing instances by
upgrading. The server additionally only emits the new status value to SDK versions that
understand it, so older clients never receive an unknown status.If an exhaustive
switchonsignIn.statusflags the new value after upgrading, handle it by
running the challenge described byprotectCheckand submitting the proof via
submitProtectCheck(). Clients should treat theprotectCheckfield as the authoritative gate
signal and fall back to the status value for defense in depth.The pre-built
<SignIn />and<SignUp />components handle the gate automatically by routing
to a newprotect-checkroute that runs the challenge SDK and resumes the flow on completion.
Patch Changes
-
Fix the payment method form getting stuck in a loading state after a failed card setup. Non-validation errors such as 3DS authentication failures are now displayed. (#9080) by @aeliox
-
Fix the organization profile modal close button overlapping the SSO configuration wizard's step header. (#9089) by @iagodahlem
-
Enlarge the show/hide password toggle button's hit area with added padding and rounded corners, making it easier to tap and giving it a clearer hover/focus target. (#9096) by @alexcarpenter
-
Polish the Protect check card: the loading spinner now hides while a challenge widget (e.g. Turnstile) is visible instead of spinning alongside it, only appears after a short delay so near-instant checks never flash it, and the card no longer reserves empty space above the spinner before a widget has rendered. (#9099) by @mwickett
-
Fix standalone
<SignUp />Protect checks so the verification card stays mounted while a solved challenge routes to the next step, while stale direct visits to the protect-check route return to the start of the sign-up flow. (#9082) by @mwickett -
Fix tooltips rendering behind modals (for example on the organization profile Security page). Tooltips now layer above modal content, and pressing Escape or clicking outside while a tooltip is open inside a modal closes only the tooltip instead of also dismissing the modal. (#9093) by @alexcarpenter
-
Updated dependencies [
6f97ef5,bab1f29,f2d9e4b]:- @clerk/shared@4.25.0
- @clerk/localizations@4.13.0
@clerk/testing@2.2.4
@clerk/tanstack-react-start@1.4.14
@clerk/shared@4.25.0
Minor Changes
-
Add support for Clerk Protect mid-flow SDK challenges (
protect_check) on both sign-up and sign-in. (#8329) by @zourzouvillysWhen the Protect antifraud service issues a challenge, responses now carry a
protectCheckfield
with{ status, token, sdkUrl, expiresAt?, uiHints? }. Clients resolve the gate by loading the
SDK atsdkUrl, executing the challenge, and submitting the resulting proof token via
signUp.submitProtectCheck({ proofToken })orsignIn.submitProtectCheck({ proofToken }). The
response may carry a chained challenge, which the SDK resolves iteratively.Sign-in adds a new
'needs_protect_check'value to theSignInStatusunion. Upgrading this
package is type-only and does not change runtime behavior: the server returns the new status
(and theprotectCheckfield) only for instances where Protect mid-flow challenges have been
explicitly enabled — the feature is off by default and is not enabled for existing instances by
upgrading. The server additionally only emits the new status value to SDK versions that
understand it, so older clients never receive an unknown status.If an exhaustive
switchonsignIn.statusflags the new value after upgrading, handle it by
running the challenge described byprotectCheckand submitting the proof via
submitProtectCheck(). Clients should treat theprotectCheckfield as the authoritative gate
signal and fall back to the status value for defense in depth.The pre-built
<SignIn />and<SignUp />components handle the gate automatically by routing
to a newprotect-checkroute that runs the challenge SDK and resumes the flow on completion.
Patch Changes
-
Fix the
touchSessionoption documentation to link directly to the Frontend API touch endpoint. (#9097) by @SarahSoutoul -
Polish the Protect check card: the loading spinner now hides while a challenge widget (e.g. Turnstile) is visible instead of spinning alongside it, only appears after a short delay so near-instant checks never flash it, and the card no longer reserves empty space above the spinner before a widget has rendered. (#9099) by @mwickett