feat: add My Account API support on the web platform - #1608
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (4)
📝 WalkthroughWalkthroughThe web platform now implements My Account API operations through Auth0 SPA JS, including authentication-method management, factor enrollment, passkey WebAuthn enrollment, DPoP handling, MRRT-based demo flows, tests, error handling, and updated documentation. ChangesWeb My Account API
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant WebDemo
participant WebAuth0Client
participant WebMyAccountClient
participant Auth0SPA
WebDemo->>Auth0SPA: getApiCredentials for /me/ audience
WebDemo->>WebMyAccountClient: invoke My Account operation with token
WebMyAccountClient->>Auth0SPA: create fetcher and call API
Auth0SPA-->>WebMyAccountClient: return enrollment or account response
WebMyAccountClient-->>WebDemo: return mapped domain result
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (6)
src/platforms/web/adapters/__tests__/WebMyAccountClient.spec.ts (2)
338-363: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueGuard the
try/catchassertion block.If
getFactorsunexpectedly resolves, thecatchbody never runs and the test passes silently. Addexpect.assertions(4)(or afail()after the awaited call) so the field assertions are guaranteed to execute.🤖 Prompt for 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. In `@src/platforms/web/adapters/__tests__/WebMyAccountClient.spec.ts` around lines 338 - 363, Add an assertion-count guard to the try/catch section of the “wraps MyAccountApiError into MyAccountError with parsed fields” test, ensuring all four error-field assertions execute and the test fails if client.getFactors unexpectedly resolves.
88-336: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winEnrollment coverage skips several implemented paths.
enrollEmail,enrollPushNotification,getAuthenticationMethodById, andconfirmEmail/TOTP/PushNotificationhave no cases, so a wrongtypeliteral in any of thoseenrollmentVerify/enrollmentChallengecalls would ship undetected. A parameterizedit.eachover the type strings would close this cheaply.🤖 Prompt for 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. In `@src/platforms/web/adapters/__tests__/WebMyAccountClient.spec.ts` around lines 88 - 336, Add focused parameterized tests in the enrollment challenge/verify suites for enrollEmail, enrollPushNotification, getAuthenticationMethodById, and confirmEmail, confirmTOTP, and confirmPushNotification. Use it.each over the relevant type literals and assert each enrollmentChallenge/enrollmentVerify call receives the correct type, location, and required mapped fields, covering the implemented paths without changing production code.Source: Coding guidelines
src/platforms/web/adapters/WebMyAccountClient.ts (3)
100-126: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReplace the
Record<string, any>escape hatch with typed access.
SpaAuthenticationMethodis already a typed snake_case shape; casting throughRecord<string, any>drops all compile-time checking on 20 field mappings, so a renamed/removed upstream field silently becomesundefined. Same pattern at Lines 147-150 and 172.As per coding guidelines, "Avoid using
anytypes; use strict TypeScript typing instead".🤖 Prompt for 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. In `@src/platforms/web/adapters/WebMyAccountClient.ts` around lines 100 - 126, Update mapAuthenticationMethod and the corresponding mappings around the referenced later sections to access SpaAuthenticationMethod fields directly, removing the Record<string, any> cast. Preserve the existing snake_case-to-camelCase mapping while relying on the typed interface so invalid or renamed fields are caught at compile time.Source: Coding guidelines
297-383: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueFive
confirm*Enrollmentbodies differ only bytypeand the OTP field.A single private
verifyEnrollment(accessToken, type, id, authSession, otpCode?)helper would collapse ~85 lines while keeping the public signatures intact.🤖 Prompt for 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. In `@src/platforms/web/adapters/WebMyAccountClient.ts` around lines 297 - 383, Add a private verifyEnrollment helper in WebMyAccountClient that accepts accessToken, enrollment type, id, authSession, and optional otpCode, performs the shared enrollmentVerify request, maps the response with mapAuthenticationMethod, and preserves MyAccountError handling through run. Refactor confirmPhoneEnrollment, confirmEmailEnrollment, confirmTOTPEnrollment, confirmPushNotificationEnrollment, and confirmRecoveryCodeEnrollment to retain their existing public signatures while delegating to this helper with the appropriate type and OTP value.
130-133: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winPublic methods lack JSDoc.
The class-level comment is good, but none of the ~17 public methods are documented — notably the web-specific DPoP constraint on
accessTokenand the WebAuthn-serializedauthResponsecontract, which differ from native.As per coding guidelines, "Use JSDoc comments to document all public APIs" and "Document platform-specific behavior in JSDoc".
🤖 Prompt for 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. In `@src/platforms/web/adapters/WebMyAccountClient.ts` around lines 130 - 133, Document every public method in WebMyAccountClient with JSDoc, including passkeyEnrollmentChallenge and the other web adapter APIs. Describe each method’s purpose, the web-specific DPoP requirement for accessToken, and the WebAuthn-serialized authResponse contract where applicable, while preserving the existing method behavior and signatures.Source: Coding guidelines
src/platforms/web/adapters/__tests__/WebAuth0Client.spec.ts (1)
207-209: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueAssertion is narrower than the test name.
The title claims the client is "wired with the shared spa-js client", but only
instanceofis checked — the constructor args (spa client, domain,useDPoP) are untested. Either rename or assert on the constructor arguments via a spy.🤖 Prompt for 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. In `@src/platforms/web/adapters/__tests__/WebAuth0Client.spec.ts` around lines 207 - 209, Strengthen the test named “should provide a WebMyAccountClient wired with the shared spa-js client” by spying on the WebMyAccountClient constructor and asserting it receives the shared spa-js client, domain, and useDPoP values; retain the instance assertion only if useful. Alternatively, rename the test to describe only the instanceof behavior.
🤖 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 `@example/src/App.web.tsx`:
- Around line 1856-1864: Remove the duplicate hint entry in the styles object
and consolidate the intended color, fontStyle, and marginBottom properties into
the single hint definition. Update the existing hint style near subheading and
buttonGroup; do not leave multiple hint keys.
- Line 364: Remove the debug console.log statement that logs challenge and its
enrollment authSession; leave the surrounding App component logic unchanged.
- Around line 410-433: Update enrollment state handling so the factor type is
preserved separately from the two-value enrollment kind. Adjust onEnrollPhone,
onEnrollEmail, and onEnrollTOTP to store their matching factor types, then
update onConfirmEnrollment to dispatch phone, email, and TOTP factors through
the appropriate confirmation flow so enrollmentVerify receives the correct type.
In `@src/platforms/web/adapters/WebMyAccountClient.ts`:
- Around line 164-169: Update the passkey flow in run so
JSON.parse(authResponse) errors are caught and converted to the expected
PasskeyError, preserving the contract that every passkey operation reports
mapped errors rather than raw SyntaxError instances. Keep valid JSON processing
and the existing EnrollmentVerifyOptions construction unchanged.
- Around line 83-94: Normalize the My Account error type in the
MyAccountApiError handling branch before constructing AuthError: map URI-style
values such as A0E-400-INVALID_PASSKEY to the corresponding PasskeyError code,
including the existing unknown-error fallback, and pass that normalized code as
AuthError’s type/code while preserving the original API details in the
serialized payload.
---
Nitpick comments:
In `@src/platforms/web/adapters/__tests__/WebAuth0Client.spec.ts`:
- Around line 207-209: Strengthen the test named “should provide a
WebMyAccountClient wired with the shared spa-js client” by spying on the
WebMyAccountClient constructor and asserting it receives the shared spa-js
client, domain, and useDPoP values; retain the instance assertion only if
useful. Alternatively, rename the test to describe only the instanceof behavior.
In `@src/platforms/web/adapters/__tests__/WebMyAccountClient.spec.ts`:
- Around line 338-363: Add an assertion-count guard to the try/catch section of
the “wraps MyAccountApiError into MyAccountError with parsed fields” test,
ensuring all four error-field assertions execute and the test fails if
client.getFactors unexpectedly resolves.
- Around line 88-336: Add focused parameterized tests in the enrollment
challenge/verify suites for enrollEmail, enrollPushNotification,
getAuthenticationMethodById, and confirmEmail, confirmTOTP, and
confirmPushNotification. Use it.each over the relevant type literals and assert
each enrollmentChallenge/enrollmentVerify call receives the correct type,
location, and required mapped fields, covering the implemented paths without
changing production code.
In `@src/platforms/web/adapters/WebMyAccountClient.ts`:
- Around line 100-126: Update mapAuthenticationMethod and the corresponding
mappings around the referenced later sections to access SpaAuthenticationMethod
fields directly, removing the Record<string, any> cast. Preserve the existing
snake_case-to-camelCase mapping while relying on the typed interface so invalid
or renamed fields are caught at compile time.
- Around line 297-383: Add a private verifyEnrollment helper in
WebMyAccountClient that accepts accessToken, enrollment type, id, authSession,
and optional otpCode, performs the shared enrollmentVerify request, maps the
response with mapAuthenticationMethod, and preserves MyAccountError handling
through run. Refactor confirmPhoneEnrollment, confirmEmailEnrollment,
confirmTOTPEnrollment, confirmPushNotificationEnrollment, and
confirmRecoveryCodeEnrollment to retain their existing public signatures while
delegating to this helper with the appropriate type and OTP value.
- Around line 130-133: Document every public method in WebMyAccountClient with
JSDoc, including passkeyEnrollmentChallenge and the other web adapter APIs.
Describe each method’s purpose, the web-specific DPoP requirement for
accessToken, and the WebAuthn-serialized authResponse contract where applicable,
while preserving the existing method behavior and signatures.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 121bb551-7155-4cc1-b2b7-0ee094c7bb96
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (10)
EXAMPLES-WEB.mdEXAMPLES.mdREADME.mdexample/src/App.web.tsxexample/src/passkey/webPasskey.tspackage.jsonsrc/platforms/web/adapters/WebAuth0Client.tssrc/platforms/web/adapters/WebMyAccountClient.tssrc/platforms/web/adapters/__tests__/WebAuth0Client.spec.tssrc/platforms/web/adapters/__tests__/WebMyAccountClient.spec.ts
…into feat/web-my-account-api-support # Conflicts: # example/src/App.web.tsx
The My Account API is fully available on iOS and Android but was previously unsupported on the web platform, where every method threw
UnsupportedOperation. This PR implements web support so thatauth0.myAccountworks consistently across all platforms, backed by@auth0/auth0-spa-js.Web consumers can now:
Summary by CodeRabbit
New Features
Bug Fixes
Documentation