Repository navigation
feat(api): fill the Clerk.auth gaps the prebuilt UI needs - #1035
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (8)
Included review availability: This review used your included allowance. 7 included reviews remain after this review. Your included PR review attempts over the past 7 days set your current allowance at 8 reviews per hour. 📝 WalkthroughWalkthroughAuth adds configurable OAuth and Enterprise SSO redirects, transfer options, passkey preferences, and transfer methods. SignIn adds general identifier input, redirect authentication, custom email-link redirects, and dedicated email and phone reset-code methods. Deprecated overloads retain selected prior method signatures. ChangesAuthentication API extensions
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~25 minutes Change: Feature Suggested reviewers: Merge Risk: ⚪ Minimal · up to This change adds Clerk.auth facade options and keeps the earlier method signatures through hidden deprecated overloads. No merge-blocking issue was identified. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
accbc9e to
e8877cd
Compare
e8877cd to
2f59745
Compare
Every old-layer call the prebuilt UI makes now has a Clerk.auth equivalent:
- signInWithOAuth(provider, transferable, redirectUrl)
- signUpWithOAuth(provider, redirectUrl, unsafeMetadata)
- signInWithPasskey(preferImmediatelyAvailableCredentials)
- signInWithGoogleOneTap(transferable), now the implementation behind
SignIn.authenticateWithGoogleOneTap and signUpWithGoogleOneTap
- signIn { identifier = ... } for single-field identifier input
- SignIn.authenticateWithOAuth / authenticateWithEnterpriseSso, which continue
an existing sign-in through a redirect factor
- SignIn.sendResetPasswordEmailCode / sendResetPasswordPhoneCode by factor id;
sendResetPasswordCode {} now delegates to them
Each widened method keeps its previous JVM signature as a hidden overload.
SignIn.create(Passkey, prefer...) and SignIn.authenticateWithGoogleOneTap
delegate to the new facade methods.
…and reset docs identifier silently lost to email, phone or username when combined with them; signIn now rejects the combination. The OAuth redirectUrl KDoc now says a custom value must be routed to SSOReceiverActivity, since handle() only completes clerk-scheme OAuth callbacks. The reset-code KDoc now says a null id picks the first reset factor regardless of address, and an explicit id is sent as given. Add tests for SignIn.create(Passkey, preferImmediatelyAvailableCredentials), no redirect after a failed prepare, and the null-id reset fallback.
…rprise SSO options Close the gaps that kept old entry points without a replacement: - Clerk.auth.transferToSignIn() / transferToSignUp() complete a transfer after signUpWithIdToken / signInWithIdToken, which don't transfer on their own. - SignIn.sendEmailLink(emailAddressId, redirectUri) and SignUp.sendEmailLink(redirectUrl) take a custom callback. - EnterpriseSsoBuilder.redirectUrl, and signInWithEnterpriseSso(transferable), match what signInWithOAuth already takes. The widened functions keep hidden overloads with their previous JVM signatures.
2f59745 to
889e262
Compare
Why
Architecture review finding #9 recommends making
Clerk.auththe primary auth API and moving the prebuilt UI onto it. Today the UI can't make that move:signInWithOAuthtakes neithertransferablenorredirectUrl, and several other UI calls have no facade equivalent. This PR adds every missing piece, so the UI migration PR becomes a mechanical swap.Stack: #1026 (drift fixes) → #1034 (one implementation per operation + matrix) → this PR.
Scope
I grepped
source/uifor every old-layer auth call. The full mapping table is in #1034. Added here:Clerk.auth.signInWithOAuth(provider, transferable = true, redirectUrl = default)Clerk.auth.signUpWithOAuth(provider, redirectUrl = default, unsafeMetadata = null)Clerk.auth.signInWithPasskey(preferImmediatelyAvailableCredentials = false), for the UI's automatic passkey attemptClerk.auth.signInWithGoogleOneTap(transferable = true). It is now the implementation behindSignIn.authenticateWithGoogleOneTapandClerk.auth.signUpWithGoogleOneTap(which keeps its sign-in-first behaviour from Expose organization switcher sheet and add org list previews #665).SignInIdentifierBuilder.identifier, so a single "email, phone or username" field can callClerk.auth.signIn { identifier = text }SignIn.authenticateWithOAuth(provider, transferable, redirectUrl)andSignIn.authenticateWithEnterpriseSso(transferable, redirectUrl)continue an existing sign-in through a redirect factor (prepare + launch). These replace the UI'sprepareFirstFactor(OAuth / EnterpriseSSO)+authenticateWithPreparedRedirectpairs.SignIn.sendResetPasswordEmailCode(emailAddressId)/sendResetPasswordPhoneCode(phoneNumberId)take factor ids, which is what the UI has.sendResetPasswordCode { }now resolves the factor and delegates to them.SignIn.create(Passkey, preferImmediatelyAvailableCredentials)andSignIn.authenticateWithGoogleOneTapnow delegate to the facade methods above.No UI call sites change here, and nothing is deprecated. The deprecation of the old layer with
ReplaceWithfollows once the UI migration lands. Deprecating now would flood:source:uiwith warnings.Blast Radius
Authmethods keep their previous JVM signatures as@Deprecated(level = HIDDEN)overloads, and a test checks they still exist. If build: check the public ABI against checked-in dumps #1022 (ABI dumps) lands first, the dump will show the new overloads and nothing removed.publicmodifiers. That is a mechanical rebase fix.Strategy, feat(api): add sealed OAuthResult.Outcome and drop UI force-unwraps #1030OAuthResult.outcome): the new signatures takeOAuthProvider/String/Booleanand returnOAuthResult, so they don't depend on either PR and can switch toStrategylater without changing callers. TurningOAuthResultitself into a sealed type is deferred to item 9's follow-up (UI migration + deprecation).Testing
AuthFacadeUiGapsTest(new, 10 cases): each new parameter or method reaches the right service with the right arguments. It also checks the reset-by-id local failure, the existing-sign-in redirect continuation, and that the old JVM signatures still exist. Against refactor(api): route both auth API layers through one implementation per operation #1034 the file doesn't compile, because the APIs it tests don't exist yet.AuthTest: the two Google One Tap tests now mockGoogleSignInService, since the facade no longer goes throughSignIn.authenticateWithGoogleOneTap../gradlew :source:api:spotlessApply :source:api:detekt :source:api:testDebugUnitTest: all pass../gradlew :source:ui:testDebugUnitTest :source:ui:detekt: all pass../gradlew :samples:linear-clone:compileDebugKotlin: compiles. It callssignInWithOAuth/signInWithPasskey.🤖 Generated with Claude Code
Review follow-ups
"Guard the new identifier field and clarify facade redirect and reset docs":
signIn { identifier = … }now rejectsidentifiercombined withemail/phone/username. Before, the identifier silently lost.redirectUrlKDoc onsignInWithOAuth/signUpWithOAuth/authenticateWithOAuth/authenticateWithEnterpriseSsonow says a custom value must be routed toSSOReceiverActivity, becauseClerk.auth.handle()only completesclerk-scheme OAuth callbacks. Changinghandle()to route any URI while SSO is pending would cancel the flow on unrelated deep links, so I documented it instead.sendResetPasswordEmailCode/PhoneCodeKDoc says a null id picks the first reset factor whatever its address, and an explicit id is sent as given.SignIn.create(Passkey, preferImmediatelyAvailableCredentials = true), no redirect after a failed prepare, and the null-id reset fallback."Add facade transfers, custom email-link redirects and Enterprise SSO options" closes the gaps that kept old entry points in #1039 without a replacement:
Clerk.auth.transferToSignIn()/transferToSignUp()complete a transfer aftersignUpWithIdToken/signInWithIdToken, which don't transfer on their own.SignIn.sendEmailLink(emailAddressId, redirectUri)andSignUp.sendEmailLink(redirectUrl)take a custom callback.EnterpriseSsoBuilder.redirectUrlandsignInWithEnterpriseSso(transferable) { }match whatsignInWithOAuthalready takes.Summary by CodeRabbit
New Features
Bug Fixes