-
Notifications
You must be signed in to change notification settings - Fork 57
Injiweb 1795 sync release to develop #469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Injiweb 1795 sync release to develop #469
Conversation
WalkthroughThis PR introduces comprehensive OpenID4VP integration documentation and refactors the codebase to support verifier-presented (VP) authorization flows. Changes include routing updates to use the new Changes
Sequence DiagramsequenceDiagram
participant User
participant VPAuthPage as VPAuthorizationPage<br/>(State Management)
participant API as Backend API
participant TrustModal as TrustVerifierModal
participant CredModal as CredentialRequestModal
participant ShareHandler as CredentialShareHandler
User->>VPAuthPage: Mount with verifier request params
VPAuthPage->>API: validateVerifierRequestCallback<br/>(validate verifier request)
API-->>VPAuthPage: verificationData & presentationId
alt Verifier Not Trusted
VPAuthPage->>TrustModal: Show TrustVerifierModal
User->>TrustModal: Accept verifier
TrustModal->>API: addTrustedVerifierCallback<br/>(add to trusted list)
API-->>TrustModal: Success
TrustModal->>VPAuthPage: onTrustComplete()
end
VPAuthPage->>CredModal: Show CredentialRequestModal
User->>CredModal: Select credentials & confirm
CredModal->>VPAuthPage: handleCredentialRequestConsent
VPAuthPage->>ShareHandler: Present selectedCredentials
ShareHandler->>API: submitPresentation<br/>(create VP and POST to response_uri)
API-->>ShareHandler: Success/Error
ShareHandler->>VPAuthPage: Callback with result
alt Success
VPAuthPage->>User: Complete flow
else Error
VPAuthPage->>VPAuthPage: Show ErrorCard with retry
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 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 |
…i#452) * [INJIWEB-1747] Removed the Authorization request url param from UserAuthorizationPage Signed-off-by: Rudhhi Shah <[email protected]> * [INJIWEB-1747] Modified the OpenIDVP authorize prefix to be appended in the validateVerifierRequest Signed-off-by: Rudhhi Shah <[email protected]> --------- Signed-off-by: Rudhhi Shah <[email protected]> Signed-off-by: kongadurgesh <[email protected]>
* [INJIWEB-1747] modified the Authorization page to fix the ?? issue in url Signed-off-by: Rudhhi Shah <[email protected]> * [INJIWEB-1747] acknowledged coderabbit comment to handle edge case on cleanParams Signed-off-by: Rudhhi Shah <[email protected]> * [INJIWEB-1747] Added new test cases in Auth and UserAuth Page Signed-off-by: Rudhhi Shah <[email protected]> --------- Signed-off-by: Rudhhi Shah <[email protected]> Signed-off-by: kongadurgesh <[email protected]>
…g, Update Props (inji#461) * [INJIWEB-1783] - Fix PR review comments Signed-off-by: kongadurgesh <[email protected]> * [INJIWEB-1783] - Fix Test case after refractor Signed-off-by: kongadurgesh <[email protected]> * [INJIWEB-1779] - Update VerifierPresentationPage to VPAuthorizationPage Signed-off-by: kongadurgesh <[email protected]> * [INJIWEB-1783] - Update VerifierPresentationPage to VPAuthorizationPage Signed-off-by: kongadurgesh <[email protected]> * [INJIWEB-1783] - Fix InfoTooltipProps Signed-off-by: kongadurgesh <[email protected]> * [INJIWEB-1783] - Rename test file to VPAuthorizationPage Signed-off-by: kongadurgesh <[email protected]> * [INJIWEB-1783] - Update file name from VPAuthorization to VPAuthorizationPage Signed-off-by: kongadurgesh <[email protected]> * [INJIWEB-1783] - Update from VPAuthorization to VPAuthorizationPage Signed-off-by: kongadurgesh <[email protected]> --------- Signed-off-by: kongadurgesh <[email protected]>
* [INJIWEB-1770] Create integration guide for OVP flow Signed-off-by: jackjain <[email protected]> * [INJIWEB-1770] Fix code review comments Signed-off-by: jackjain <[email protected]> * [INJIWEB-1770] Add separate sequence diagram for user rejects verifier flow, fix typos and add more details to descriptions Signed-off-by: jackjain <[email protected]> * [INJIWEB-1770] Fix grammar in URL param description Signed-off-by: jackjain <[email protected]> --------- Signed-off-by: jackjain <[email protected]> Signed-off-by: kongadurgesh <[email protected]>
Signed-off-by: kongadurgesh <[email protected]>
f5c866f to
86ea721
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
inji-web/src/utils/errorHandling.ts (1)
17-35: Inconsistent comment:ERROR_TYPESis exported.The comment on line 17 states these are "not exported," but
ERROR_TYPESis actually exported on line 18.-// Internal error types and mappings (not exported as they're only used internally) +// Standard error types for categorizing errors across the application export const ERROR_TYPES = {inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1)
20-41: Escape key should always close, not toggle the tooltipUsing the same toggle logic for
Escape,Enter, and space means pressingEscapewhen the tooltip is hidden will open it, which is counter to typical a11y expectations (Escape is expected to close only).Consider handling
Escapeseparately to always hide the tooltip:- onKeyDown={(e) => { if (e.key === 'Escape' || e.key === 'Enter' || e.key === ' ') { e.preventDefault(); e.stopPropagation(); handleToggle(); } }} + onKeyDown={(e) => { + if (e.key === 'Escape') { + e.preventDefault(); + e.stopPropagation(); + setShowTooltip(false); + return; + } + if (e.key === 'Enter' || e.key === ' ') { + e.preventDefault(); + e.stopPropagation(); + handleToggle(); + } + }}
🧹 Nitpick comments (8)
docs/OpenID4VPIntegrationGuide.md (2)
13-16: Refine sentence variety in the high-level flow section.Lines 13–16 have three consecutive sentences starting with "User," reducing stylistic variety. Consider rephrasing to improve readability:
- Verifier constructs an OpenID4VP authorization request. - User is redirected to the INJI Web Wallet (`/authorize`). - User logs in. - User reviews verifier details and gives consent. - User selects an eligible credential matching the `presentation_definition`.Try something like:
- Verifier constructs an OpenID4VP authorization request. - User is redirected to the INJI Web Wallet (`/authorize`) and logs in. - After authentication, the user reviews verifier details and grants consent. - Credential matching the `presentation_definition` is then selected by the user.
1-429: Comprehensive and well-structured documentation.The guide covers all essential aspects of OpenID4VP integration: authorization flow, parameter requirements, presentation definitions, client metadata, VP delivery, security considerations, and detailed technical specifications with sequence diagrams. The examples, parameter tables, and error handling section provide practical guidance for implementers.
A few minor notes:
- Confirm that the documented endpoints and parameter names match the actual implementation.
- Consider clarifying the boundary between InjiWeb frontend responsibilities and Mimoto backend responsibilities earlier in the document.
- The references section at the end is valuable; ensure links remain current.
inji-web/src/hooks/useApiErrorHandler.ts (1)
15-33: Consider renamingUseApiErrorHandlerPropstoUseApiErrorHandlerResultor similar.The suffix
Propstypically denotes input properties to a component/hook, while this interface describes the return value. A name likeUseApiErrorHandlerResultorUseApiErrorHandlerReturnwould be more idiomatic.-export interface UseApiErrorHandlerProps { +export interface UseApiErrorHandlerResult {And update the return type accordingly:
export const useApiErrorHandler = ( retryConfig: RetryConfig = {} -): UseApiErrorHandlerProps => { +): UseApiErrorHandlerResult => {Also applies to: 47-47
inji-web/src/pages/VPAuthorizationPage.tsx (4)
24-24: Consider adding a type forverifierDatainstead ofany.Using
anyloses type safety. Consider defining an interface for the verifier data structure.+interface VerifierData { + id: string; + name: string; + logo?: string; + trusted: boolean; + redirectUri?: string; +} + export const VPAuthorizationPage: React.FC = () => { // ... - const [verifierData, setVerifierData] = useState<any>(null); + const [verifierData, setVerifierData] = useState<VerifierData | null>(null);
71-79: Simplify the parameter validation logic.The try-catch here is misleading since the condition check won't throw an exception. The error is manually thrown, making the catch block unreachable in practice.
- try { - if (!cleanParams || cleanParams === '?') { - throw new Error("No query parameters found in URL"); - } - } catch (parseError) { - setIsLoading(false); - handleApiError(new Error("Invalid authorization request URL."), "validateVerifierRequest"); - return; - } + if (!cleanParams || cleanParams === '?') { + handleApiError(new Error("Invalid authorization request URL."), "validateVerifierRequest"); + return; + }
201-210: Minor: Redundant visibility check.
CredentialRequestModalis conditionally rendered with&&and also receivesisVisibleprop. The outer condition already guarantees the modal should be shown.{showCredentialRequest && presentationIdData && ( <CredentialRequestModal - isVisible={showCredentialRequest && !isErrorActive} + isVisible={!isErrorActive} verifierName={verifierData?.name || 'Verifier'}
51-66: State setters in dependency arrays are unnecessary.React guarantees that state setter functions (like
setVerifierData,setShowTrustVerifier) are stable and don't change between renders. Including them in dependency arrays is harmless but adds noise.- }, [setPresentationIdData, setVerifierData, setShowTrustVerifier, setShowCredentialRequest]); + }, []); - }, [setShowTrustVerifier, setShowCredentialRequest]); + }, []);Also applies to: 100-104, 116-119
inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1)
43-47: Alignalttext witharia-hiddenon the iconSince the icon is marked
aria-hidden="true", screen readers will ignore it, so thealt="Information icon"text is unused. For clarity and conventional a11y practice, you can set an empty alt:- alt="Information icon" - aria-hidden="true" + alt="" + aria-hidden="true"This keeps the icon purely decorative while making the intent explicit.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
inji-web/src/__tests__/components/Common/ToolTip/__snapshots__/InfoTooltip.test.tsx.snapis excluded by!**/*.snapinji-web/src/__tests__/pages/__snapshots__/VPAuthorizationPage.test.tsx.snapis excluded by!**/*.snap
📒 Files selected for processing (24)
docs/OpenID4VPIntegrationGuide.md(1 hunks)inji-web/src/Router.tsx(2 hunks)inji-web/src/__tests__/components/Common/ToolTip/InfoTooltip.test.tsx(2 hunks)inji-web/src/__tests__/components/Issuer/TrustVerifierModal.test.tsx(1 hunks)inji-web/src/__tests__/handlers/CredentialShareHandler.test.tsx(1 hunks)inji-web/src/__tests__/hooks/useApiErrorHandler.test.ts(1 hunks)inji-web/src/__tests__/modals/CredentialRequestModal.test.tsx(1 hunks)inji-web/src/__tests__/modals/LoaderModal.test.tsx(1 hunks)inji-web/src/__tests__/pages/VPAuthorizationPage.test.tsx(6 hunks)inji-web/src/__tests__/utils/errorHandling.test.ts(10 hunks)inji-web/src/components/Common/ToolTip/InfoTooltip.tsx(1 hunks)inji-web/src/components/Credentials/CredentialItem.tsx(2 hunks)inji-web/src/components/Issuers/TrustVerifierModal.tsx(2 hunks)inji-web/src/components/PageTemplate/PasscodePage/PasscodePageTemplate.tsx(1 hunks)inji-web/src/handlers/CredentialShareHandler.tsx(3 hunks)inji-web/src/hooks/useApiErrorHandler.ts(4 hunks)inji-web/src/hooks/useInterceptor.ts(1 hunks)inji-web/src/modals/CredentialRequestModal.tsx(4 hunks)inji-web/src/modals/LoaderModal.tsx(1 hunks)inji-web/src/modals/NoMatchingCredentialsModal.tsx(2 hunks)inji-web/src/pages/User/Passcode/PasscodePage.tsx(1 hunks)inji-web/src/pages/VPAuthorizationPage.tsx(1 hunks)inji-web/src/types/components.d.ts(0 hunks)inji-web/src/utils/errorHandling.ts(2 hunks)
💤 Files with no reviewable changes (1)
- inji-web/src/types/components.d.ts
🧰 Additional context used
🧠 Learnings (5)
📚 Learning: 2025-11-11T13:34:35.642Z
Learnt from: kongadurgesh
Repo: mosip/inji-web PR: 454
File: inji-web/src/components/Issuers/TrustRejectionModal.tsx:43-51
Timestamp: 2025-11-11T13:34:35.642Z
Learning: In inji-web, the TrustRejectionModal component does not require additional local error handling or loading states for the handleConfirm callback. The error handling in rejectVerifierRequest (via withErrorHandling) is sufficient and has been tested for blocked scenarios.
Applied to files:
inji-web/src/modals/CredentialRequestModal.tsxinji-web/src/__tests__/handlers/CredentialShareHandler.test.tsxinji-web/src/handlers/CredentialShareHandler.tsxinji-web/src/pages/VPAuthorizationPage.tsxinji-web/src/modals/NoMatchingCredentialsModal.tsxinji-web/src/__tests__/modals/CredentialRequestModal.test.tsxinji-web/src/__tests__/components/Issuer/TrustVerifierModal.test.tsxinji-web/src/components/Issuers/TrustVerifierModal.tsx
📚 Learning: 2025-10-22T13:49:57.892Z
Learnt from: kongadurgesh
Repo: mosip/inji-web PR: 442
File: inji-web/src/components/Credentials/PresentationCredentialList.tsx:37-37
Timestamp: 2025-10-22T13:49:57.892Z
Learning: In inji-web/src/components/Credentials/PresentationCredentialList.tsx, the format field is hardcoded as 'ldp_vc' because currently only ldp_vc credential format is supported. Other credential formats (like jwt) are planned for future scope.
Applied to files:
inji-web/src/modals/CredentialRequestModal.tsxinji-web/src/handlers/CredentialShareHandler.tsxinji-web/src/components/Credentials/CredentialItem.tsx
📚 Learning: 2025-10-16T09:49:00.207Z
Learnt from: kongadurgesh
Repo: mosip/inji-web PR: 438
File: inji-web/src/utils/api.ts:290-305
Timestamp: 2025-10-16T09:49:00.207Z
Learning: In the inji-web application, the Authorization page (UserAuthorizationPage) ensures users are redirected to login if walletId is missing. The walletId is guaranteed to exist in AppStorage (KEYS.WALLET_ID) during normal credential request flows.
Applied to files:
inji-web/src/hooks/useInterceptor.tsdocs/OpenID4VPIntegrationGuide.md
📚 Learning: 2025-11-10T06:31:44.815Z
Learnt from: Rudhhi-Shah-14
Repo: mosip/inji-web PR: 453
File: inji-web/src/pages/AuthorizationPage.tsx:22-25
Timestamp: 2025-11-10T06:31:44.815Z
Learning: In inji-web/src/pages/AuthorizationPage.tsx, the URL construction for redirecting to /user/authorize intentionally checks if window.location.search starts with '?' to avoid double question marks. A trailing '?' when window.location.search is empty is acceptable and doesn't affect behavior.
Applied to files:
inji-web/src/__tests__/pages/VPAuthorizationPage.test.tsxinji-web/src/pages/VPAuthorizationPage.tsxinji-web/src/Router.tsx
📚 Learning: 2025-11-11T04:37:04.453Z
Learnt from: kongadurgesh
Repo: mosip/inji-web PR: 454
File: inji-web/src/utils/verifierUtils.ts:47-48
Timestamp: 2025-11-11T04:37:04.453Z
Learning: In inji-web, the redirectUri used in verifierUtils.rejectVerifierRequest does not require frontend validation because it is already validated by the backend API (api.validateVerifierRequest) as part of the payload. The backend validation is considered sufficient for security.
Applied to files:
inji-web/src/modals/NoMatchingCredentialsModal.tsx
🧬 Code graph analysis (6)
inji-web/src/__tests__/pages/VPAuthorizationPage.test.tsx (1)
inji-web/src/pages/VPAuthorizationPage.tsx (1)
VPAuthorizationPage(18-250)
inji-web/src/pages/VPAuthorizationPage.tsx (5)
inji-web/src/types/components.d.ts (1)
PresentationCredential(119-124)inji-web/src/hooks/useApi.ts (1)
useApi(28-156)inji-web/src/hooks/User/useUser.tsx (1)
useUser(4-10)inji-web/src/hooks/useApiErrorHandler.ts (1)
useApiErrorHandler(45-162)inji-web/src/utils/constants.ts (2)
ROUTES(24-39)OPENID4VP_AUTHORIZE_PREFIX(67-67)
inji-web/src/__tests__/utils/errorHandling.test.ts (1)
inji-web/src/utils/errorHandling.ts (4)
standardizeError(40-71)ERROR_TYPES(18-28)StandardError(6-9)logError(76-93)
inji-web/src/components/Issuers/TrustVerifierModal.tsx (1)
inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1)
InfoTooltip(13-79)
inji-web/src/__tests__/components/Common/ToolTip/InfoTooltip.test.tsx (1)
inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1)
InfoTooltip(13-79)
inji-web/src/Router.tsx (2)
inji-web/src/utils/constants.ts (1)
Pages(8-21)inji-web/src/pages/VPAuthorizationPage.tsx (1)
VPAuthorizationPage(18-250)
🪛 LanguageTool
docs/OpenID4VPIntegrationGuide.md
[style] ~15-~15: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...let (/authorize). 3. User logs in. 4. User reviews verifier details and gives cons...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~16-~16: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... verifier details and gives consent. 5. User selects an eligible credential matching...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build-ui-test-local
- GitHub Check: inji-web / build-dockers
- GitHub Check: Analyze (java-kotlin)
🔇 Additional comments (36)
inji-web/src/hooks/useInterceptor.ts (1)
38-38: Good catch on the typo.Minor grammar correction in the comment improves clarity. No behavioral changes.
docs/OpenID4VPIntegrationGuide.md (1)
294-300: Verify Mimoto endpoint accuracy.The technical specification references several Mimoto endpoints (e.g.,
POST /wallets/{walletId}/presentations,PATCH /wallets/{walletId}/presentations/{presentationId}). Ensure these endpoints and their signatures match the actual Mimoto API implementation.inji-web/src/pages/User/Passcode/PasscodePage.tsx (1)
291-299: UpdatedtestIdcomposition correctly mirrors previous behavior and new template APIComposing
testIdaspasscode${testIdSuffix}(withtestIdSuffixcarrying the leading-only for lock states) preserves the old effective IDs ("passcode","passcode-temporarily-locked", etc.) while matching the newPasscodePageTemplatesingle-testIdAPI. No functional regressions evident here.inji-web/src/components/Issuers/TrustVerifierModal.tsx (2)
5-5: LGTM! Component rename applied consistently.The import and usage have been updated correctly to reflect the
InfoTooltipTrigger→InfoTooltiprename. The component interface remains unchanged.Also applies to: 130-134
5-10: LGTM! Clean component and interface rename.The rename from
InfoTooltipTriggertoInfoTooltipis well-executed with no functional changes. The component interface and behavior remain identical.Also applies to: 13-18
inji-web/src/__tests__/components/Common/ToolTip/InfoTooltip.test.tsx (1)
4-4: LGTM! Test references updated correctly.The test file has been updated to import and render
InfoTooltipinstead ofInfoTooltipTrigger. All test coverage is preserved.Also applies to: 8-8, 17-17
inji-web/src/__tests__/components/Issuer/TrustVerifierModal.test.tsx (1)
62-68: LGTM! Mock updated to match renamed component.The mock module path and export name have been correctly updated from
InfoTooltipTriggertoInfoTooltip. The mock implementation remains functionally identical.inji-web/src/components/Credentials/CredentialItem.tsx (1)
13-17: Inlinememoexport is clean and behavior‑preservingDefining
CredentialItemdirectly as amemo<CredentialItemProps>(...)export removes an extra component symbol without changing props, hooks, or render logic. Import surface stays the same (CredentialItemnamed export), so this is a safe, stylistic refactor aligned with the broader inline‑memo pattern in the PR.Please just confirm TS/React build and tests pass after this refactor (no lingering references to any previous internal component name).
Also applies to: 120-120
inji-web/src/components/PageTemplate/PasscodePage/PasscodePageTemplate.tsx (1)
78-78: LGTM! Simplified test ID generation.The refactoring to remove
testIdSuffixand have the caller compose the completetestIdsimplifies the component API. According to the PR summary, PasscodePage.tsx has been updated accordingly.Verify that all callers of
PasscodePageTemplatehave been updated to match the new API, particularly checking that:
- No remaining usages pass a
testIdSuffixprop- All test IDs are composed at the call site before passing to the component
inji-web/src/modals/LoaderModal.tsx (1)
64-64: LGTM! Cosmetic whitespace cleanup.The removal of the trailing newline is a minor formatting improvement with no functional impact.
inji-web/src/__tests__/handlers/CredentialShareHandler.test.tsx (1)
15-18: LGTM! Test mock updated to align with component rename.The mock correctly reflects the LoadingModal → LoaderModal refactoring while preserving the test behavior.
inji-web/src/modals/NoMatchingCredentialsModal.tsx (1)
49-88: LGTM! Callback naming standardization.The rename from
rejectVerifierCoretorejectVerifierCallbackimproves naming consistency across the codebase. All references and dependencies are correctly updated with no logic changes.inji-web/src/__tests__/hooks/useApiErrorHandler.test.ts (1)
196-196: LGTM! Test updated for hook API change.The test correctly uses the renamed
errorCodesToRetryproperty, aligning with the updateduseApiErrorHandlerhook API.inji-web/src/__tests__/modals/LoaderModal.test.tsx (1)
3-3: LGTM! Import path updated for renamed component.The import correctly targets the LoaderModal component, consistent with the codebase-wide refactoring.
inji-web/src/__tests__/pages/VPAuthorizationPage.test.tsx (3)
5-5: LGTM! Component rename to VPAuthorizationPage.The import reflects the page component rename from UserAuthorizationPage to VPAuthorizationPage, providing more descriptive naming (VP = Verifiable Presentation).
83-88: LGTM! Mock updated to LoaderModal.The mock correctly targets LoaderModal instead of LoadingModal, consistent with the codebase-wide component rename.
247-247: LGTM! Test suite updated for component rename.All test references consistently updated from UserAuthorizationPage to VPAuthorizationPage, including renders, rerenders, and test suite description.
Also applies to: 288-288, 442-442, 534-534
inji-web/src/__tests__/modals/CredentialRequestModal.test.tsx (1)
85-93: LGTM! Test mock updated for component rename.The mock correctly reflects the LoadingModal → LoaderModal refactoring while maintaining identical test behavior.
inji-web/src/modals/CredentialRequestModal.tsx (2)
4-4: LGTM! Import updated to LoaderModal.The import correctly reflects the LoadingModal → LoaderModal component rename, consistent with the codebase-wide refactoring.
108-132: LGTM! Callback naming standardization.The rename from
fetchCredentialsCoretofetchCredentialsCallbackimproves naming consistency. All function calls, error handler references, and dependency arrays are correctly updated with no logic changes.inji-web/src/Router.tsx (1)
14-14: LGTM! Route correctly updated to use VPAuthorizationPage for authenticated user flow.The routing change properly separates the authorization flows:
- Non-user route (
/authorize) continues to useAuthorizationPage- User route (
/user/authorize) now usesVPAuthorizationPagefor the OpenID4VP flowAlso applies to: 132-132
inji-web/src/handlers/CredentialShareHandler.tsx (2)
5-5: LGTM! Import path updated to match renamed modal component.
42-51: LGTM! Callback rename improves consistency.The rename from
submitPresentationCoretosubmitPresentationCallbackaligns with the naming convention used in other parts of the codebase (e.g.,validateVerifierRequestCallbackin VPAuthorizationPage). Dependency array correctly updated.Also applies to: 57-79
inji-web/src/hooks/useApiErrorHandler.ts (1)
10-12: LGTM! Configuration field rename is consistent throughout.The rename from
retryableErrorCodestoerrorCodesToRetryis applied consistently across the interface definition, destructuring, usage, and dependency array.Also applies to: 50-52, 87-87, 119-119
inji-web/src/__tests__/utils/errorHandling.test.ts (4)
7-7: LGTM! Import updated to match renamed type.
72-72: LGTM! Test assertions updated to validate simplified StandardError structure.The tests now correctly assert
originalErrorpreservation rather than generated messages, aligning with the updatedStandardErrorinterface that contains onlycodeandoriginalError.Also applies to: 94-94, 115-116, 126-127, 137-138, 146-147
149-174: LGTM! Comprehensive HTTP status code mapping tests.Good coverage of:
- Specific status code mappings (400, 401, 404, 500)
- Fallback behavior for unmapped 4xx →
API_CLIENT- Fallback behavior for unmapped 5xx →
API_SERVER- Original error preservation
Also applies to: 176-188
191-240: LGTM! Updated logError and withErrorHandling tests.Tests correctly use
originalErrorin StandardError construction and validate error propagation throughwithErrorHandling.Also applies to: 262-263
inji-web/src/pages/VPAuthorizationPage.tsx (3)
1-16: LGTM! Well-organized imports.All necessary dependencies are imported for the VP authorization flow including modals, handlers, hooks, and navigation utilities.
171-249: LGTM! Well-structured modal orchestration.The conditional rendering of modals based on state is well organized:
LoaderModalfor loading/retrying statesTrustVerifierModalfor untrusted verifiersCredentialRequestModalfor credential selectionCredentialShareHandlerfor submissionErrorCardfor error displayTrustRejectionModalfor cancellation confirmationThe
isErrorActiveflag correctly prevents other modals from showing during error states. Based on learnings, the TrustRejectionModal error handling viawithErrorHandlingis sufficient.
159-167: Verify the useEffect dependency array forisUserLoggedIn.The
isUserLoggedInfunction reference fromuseUser()is used in the dependency array, but it's unclear whether this function reference is stable across renders. IfuseUserreturns a new function reference on each render, this effect won't behave as expected. Additionally,loadInitialDatais excluded via ESLint disable. Confirm whetherisUserLoggedInis memoized in theuseUserhook and whetherloadInitialDatashould be included in the dependency array.inji-web/src/utils/errorHandling.ts (4)
11-15: LGTM!The renamed
ErrorOptionsinterface is cleaner and the optional fields are well-structured for flexible error handling configuration.
40-71: LGTM!The simplified return structure is clean. The fallback categorization for unmapped HTTP statuses (4xx →
API_CLIENT, 5xx →API_SERVER) ensures robustness.
76-93: LGTM!The message extraction chain provides sensible fallbacks, and computing the message at log time rather than embedding it in the error object is a good separation of concerns. The ISO timestamp format is appropriate for log correlation.
98-110: LGTM!The async wrapper maintains a clean pattern for standardized error handling with proper logging integration.
inji-web/src/components/Common/ToolTip/InfoTooltip.tsx (1)
5-10: Props interface rename looks consistentThe
InfoTooltipPropsinterface matches how the component is used; prop names and optional fields align and keep the API clear. No issues here.
Summary by CodeRabbit
Release Notes
Documentation
New Features
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.