fix(ui): continue combined-flow SSO callbacks to sign-in steps - #10014
Conversation
🦋 Changeset detectedLatest commit: a879076 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (1)
🔗 Linked repositories identifiedCodeRabbit considers these linked repositories for cross-repo context during reviews:
Included review availability: This review used your included allowance. 8 included reviews remain after this review. Your included PR review attempts over the past 7 days set your current allowance at 10 reviews per hour. 📝 WalkthroughWalkthroughThe combined-flow SSO callback now uses callback parameters with relative sign-in and sign-up step URLs. The transfer handler uses a shared helper to build sign-up step URLs. Tests cover callback navigation across routing modes and Protect-check outcomes, including session activation, second-factor navigation, and continuation to an embedded sign-up route. Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The callback destinations resolve to the intended combined-flow steps within the mounted SignIn component. No actionable merge-blocking issue is identified. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 12.50% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 8 functions across 9 files. (1 skipped: 1 unsupported.)
Comment |
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/electron
@clerk/electron-passkeys
@clerk/eslint-plugin
@clerk/expo
@clerk/expo-google-signin
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/hono
@clerk/localizations
@clerk/mosaic
@clerk/nextjs
@clerk/nuxt
@clerk/react
@clerk/react-router
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/ui
@clerk/upgrade
@clerk/vue
commit: |
API Changes Report
Summary
No API Changes DetectedAll packages have stable APIs with no detected changes. Report generated by Break Check Last ran on |
…outes after a Protect check
Description
In the combined sign-in-or-up flow, the OAuth/SAML callback navigated to URLs the component's own router could not reach. That sent users back to the start card mid-flow.
create/sso-callback, where combined-flow OAuth redirects land under path/hash routing, was built withbuildSignUpOAuthCallbackParams. That builder carries no sign-in step URLs, so a callback resolving intoneeds_protect_check,needs_first_factor,needs_second_factororneeds_new_passwordfell back todisplayConfig.signInUrl#/<step>.signUpContinueUrl/signUpProtectCheckUrl, which in the combined flow are<signInUrl>#/create/*. Those routes aresso-callback, where an OAuth redirect started from the modal lands on the sign-in page, andprotect-check, when it resumes an OAuth transfer.The SSO callback hands the component router's
navigateto the handler, so a hash-form URL becomes an internal navigation to the SignIn index:BaseRouterinstalls the pathname and ignores the fragment, andPathRouterconverts hashes only in its own effect. The start card mounts and can replace the in-flight sign-in before the intended step renders. With passkey autofill it immediately creates a new passkey sign-in, and its OAuth-error handling resets the attempt withsignIn.create({}).This shows up when a Protect check gates an OAuth sign-in. The challenged create still returns the provider redirect, so the user completes Google and lands back on the callback. They are then sent to the start card, solve a check for a new passkey sign-in, tap Google again, and loop. The OAuth sign-in's own check never runs. FAPI logs for an affected session show a new
POST /v1/client/sign_ins(strategypasskey) about 1.4s after eachoauth_callback303, and noprotect_checkPATCH on the OAuth sign-in.Changes:
signUpStepUrls(prefix)producescontinue/verify-email-address/verify-phone-number/protect-checkfor a route depth. It is used bybuildSignInOAuthCallbackParams(../create/), the transport builder (create/),buildSignUpOAuthCallbackParams(../),buildSignUpOAuthTransportCallbackParams('') andhandleSignUpIfMissingTransfer(../create/).buildSignInOAuthCallbackParamsbranches onisCombinedFlow.sso-callbackandprotect-checkare siblings at the SignIn root, so the same../create/*URLs serve the root callback route andSignInProtectCheck's transfer resume. Separate sign-in/sign-up setups are unchanged.create/sso-callbackusesbuildCombinedFlowOAuthCallbackParams. It takes the sign-up step URLs plus the sign-in steps one level further up:../../protect-check,../../factor-one,../../factor-two,../../reset-password.The web3 callers (
SignInSocialButtons,SignInFactorOneSolanaWalletsCard) still pick their owncreate/*URLs, becauseauthenticateWithWeb3takes a differently named parameter set. The root cause is that the context's combined-flow URLs are hash-form. Fixing that at the context level would remove every override, but is larger than this PR.Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change