Stop showing automatic passkey sign-in errors to end users - #528
Conversation
The automatic passkey modal and the AutoFill fallback both start without user intent, so a failure has nothing for the person signing in to act on. An app that has not declared a webcredentials: associated domain for its Frontend API fails every attempt, which surfaced as a "Whoops, something is wrong" sheet over the sign-in form. Present these errors in debug builds only; every build still logs them.
An instance can enable passkeys for registration and verification while leaving them out of the sign-in factors (enabled: true with used_for_first_factor: false). AuthStartView checked only the enabled flag, so it created a passkey sign-in and prepared the first factor on every appearance of the sign-in form, against an instance that would never accept the result.
CI pausedCI does not run automatically on pull request updates. Before merging, manual CI must be run and pass for the latest commit. When this PR is ready for CI, the PR author or a repository maintainer can comment:
Or use the quick action below:
|
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 54f6f7763c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
📝 WalkthroughWalkthroughAdds Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Tests/UI/PasskeyFirstFactorAvailabilityTests.swift`:
- Around line 41-52: Add a test alongside
passkeyFirstFactorIsDisabledWhenPasskeyIsDisabled that creates an environment
with passkeyEnabled false and usedForFirstFactor false, then asserts both
passkeyIsEnabled and passkeyFirstFactorIsEnabled are false, completing the
enabled/usedForFirstFactor matrix.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 7a5c9a25-3644-4c38-b63e-61b952d770f1
📒 Files selected for processing (3)
Sources/ClerkKitUI/Components/Auth/AuthStartView.swiftSources/ClerkKitUI/Extensions/Environment+Ext.swiftTests/UI/PasskeyFirstFactorAvailabilityTests.swift
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
clerk/clerk_go(manual)clerk/dashboard(manual)clerk/accounts(manual)clerk/backoffice(manual)clerk/clerk(manual)clerk/clerk-docs(manual)clerk/cloudflare-workers(manual)
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
The debug-only gate also swallowed attemptFirstFactor failures that occur after the user selected a credential from the AutoFill suggestions or the automatic modal, leaving them silently on the sign-in form in release builds. Suppress only ASAuthorizationError in release: authorization ceremony failures are the ones that happen without user participation and are actionable only by the developer, while server rejections of a selected credential surface as ClerkAPIError and keep presenting. Also cover the disabled/not-first-factor combination in the environment tests.
ea167e2 to
d0ef3dd
Compare
|
@codex review |
|
/run ci |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d0ef3dd613
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
createPasskeySignIn runs the moment the sign-in form appears, before the credential picker is even requested, so a network or API failure there is pre-selection by construction and has nothing for the user to act on.
|
/run ci |
2 participants
Two fixes to the automatic passkey sign-in that
AuthStartViewkicks off when the sign-in form appears.1. Automatic passkey failures no longer reach end users in release builds
The automatic modal and the AutoFill fallback both start without the user doing anything, so when they fail there's nothing for the person signing in to act on. The error was still being pushed into
generalErrorand presented as a "Whoops, something is wrong" sheet on top of the sign-in form.The common trigger is an app that hasn't declared a
webcredentials:associated domain for its Frontend API. Every attempt fails withApplication with identifier <team>.<bundle-id> is not associated with domain <fapi-host>, and only the developer can fix it.These errors are now presented in debug builds only, so the misconfiguration stays obvious while integrating. Every build still logs through
ClerkLogger.Suppression is limited to
ASAuthorizationError, i.e. authorization ceremony failures. Once the user picks a passkey from the AutoFill suggestions or the automatic modal, a server rejection of that credential surfaces as aClerkAPIErrorand still presents in every build.Explicit passkey sign-in (the button in
SignInFactorOnePasskeyView) is unchanged and still surfaces errors, since the user initiated it.2. Automatic passkey sign-in only starts when passkey is a first factor
An instance can enable passkeys for registration and verification while leaving them out of the sign-in factors:
passkeySignInIsAvailablechecked onlyenabled, soAuthStartViewfiredPOST /v1/client/sign_insandprepare_first_factoron every appearance, against an instance that would never accept the assertion. AddedpasskeyFirstFactorIsEnabled, which mirrors how every other attribute is checked for sign-in, and gated the automatic flow on it.UserProfileSecurityViewkeeps usingpasskeyIsEnabled. Managing passkeys in the profile is separate from whether they're a sign-in factor.Testing
swift build,swift test --skip Integration: 1018 tests passmake format-check,make lint: clean on the changed filesTests/UI/PasskeyFirstFactorAvailabilityTests.swiftcovers the four combinations ofenabled/used_for_first_factorThe two commits are independent if you'd rather land them separately.
Note
Stop showing automatic passkey sign-in errors to end users in release builds
ASAuthorizationErrorfailures no longer setgeneralErrorinAuthStartView, so users don't see confusing automatic passkey prompts fail silently with an error. Debug builds still surface all errors.passkeyFirstFactorIsEnabledproperty toClerk.Environmentthat returns true only when the passkey attribute is both enabled and markedusedForFirstFactor. The availability check inAuthStartViewnow uses this instead of the broaderpasskeyIsEnabled.presentAutomaticPasskeyError(_:isPreSelection:)helper inAuthStartView.swiftcentralizes the conditional error-presentation logic for both autofill and immediate-credential passkey flows.Macroscope summarized 7506f95.