Skip to content

Enable Unavailable Accounts Display in Authorization Screen to Support CDS Toolkit#900

Open
duleepa-a wants to merge 14 commits intowso2:mainfrom
duleepa-a:Changes-for-CDS-DOMS-Feature
Open

Enable Unavailable Accounts Display in Authorization Screen to Support CDS Toolkit#900
duleepa-a wants to merge 14 commits intowso2:mainfrom
duleepa-a:Changes-for-CDS-DOMS-Feature

Conversation

@duleepa-a
Copy link

@duleepa-a duleepa-a commented Feb 5, 2026

Enable Unavailable Accounts Display in Authorization Screen to Support CDS Toolkit

This change enhances the Accelerator to support CDS Toolkit authorization screen requirements while keeping the implementation generic and reusable.

  • Added a reusable displayData structure to the consent authorization response to enable displaying unavailable accounts on the authorization screen, allowing the CDS Toolkit to meet its UI requirements.

  • Introduced the is_cds_deployment configuration property to control JWT signing behavior in the consent enforcement policy. Since CDS deployments include a downstream policy that performs JWT signing after consent enforcement, this configuration prevents double-signing by skipping signing at the consent enforcement stage.


Development Checklist

  1. Build complete solution with pull request in place.
  2. Ran checkstyle plugin with pull request in place.
  3. Ran Findbugs plugin with pull request in place.
  4. Ran FindSecurityBugs plugin and verified report.
  5. Formatted code according to WSO2 code style.
  6. Have you verified the PR doesn't commit any keys, passwords, tokens, usernames, or other secrets?
  7. Migration scripts written (if applicable).
  8. Have you followed secure coding standards in WSO2 Secure Engineering Guidelines?

Testing Checklist

  1. Written unit tests.
  2. Verified tests in multiple database environments (if applicable).
  3. Tested with BI enabled (if applicable).

Summary by CodeRabbit

Release Notes

  • New Features

    • Added support for displaying additional customizable sections on the consent authorization screen with tooltip functionality
    • Introduced configuration option to enable/disable response payload signing in consent validation
  • Bug Fixes

    • Fixed variable reference error in account selection script
  • Style

    • Updated documentation formatting across multiple components
    • Enhanced CSS styling for popover and hide elements
    • Code formatting improvements

@CLAassistant
Copy link

CLAassistant commented Feb 5, 2026

CLA assistant check
All committers have signed the CLA.

@coderabbitai
Copy link

coderabbitai bot commented Feb 5, 2026

Note

Reviews paused

It 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 reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

This PR enhances the consent authorization UI with additional customizable display sections, introduces response payload signing configuration, fixes a JavaScript variable reference bug, and adds numerous Javadoc punctuation improvements across multiple files.

Changes

Cohort / File(s) Summary
Javadoc Punctuation Formatting
common/...model/{ExternalServiceRequest, ExternalServiceResponse, ServiceExtensionTypeEnum, StatusEnum}.java, common/.../ServiceExtensionUtils.java, common/.../validationgroups/{AttributeChecks, MandatoryChecks, SignatureCheck, ValidationOrder}.java, consent.mgt.dao/.../ConsentManagementDAOTestDataProvider.java, consent.mgt.service/.../ConsentCoreService.java, consent.mgt.service/.../{ConsentCoreServiceTestUtils, ConsentMgtServiceTestData}.java, identity.extensions/.../{FSGrantHandler, FSDefaultIntrospectionDataProvider, IdentityServiceExtensionUtils}.java, scp/webapp/exception/TokenGenerationException.java, scp/webapp/service/{OAuthService, ResourceInterceptorService}.java
Minor documentation updates adding trailing periods to class and method Javadoc comments. No functional or behavioral changes.
Additional Display Data Model & Constants
consent.mgt.extensions/...model/PopulateConsentAuthorizeScreenDTO.java, consent.mgt.extensions/...model/AdditionalDisplayDataDTO.java, consent.mgt.extensions/.../ConsentAuthorizeConstants.java
Introduces AdditionalDisplayDataDTO as a new public data transfer object with fields for heading, subHeading, description, and displayList. Adds getter/setter methods, fluent addItem() method, and equals/hashCode implementations. New constants ADDITIONAL_DISPLAY_DATA and ADDITIONAL_DISPLAY_SECTION_TAG added to support dynamic UI sections.
Additional Display Data Backend Integration
consent.mgt.extensions/.../ExternalAPIConsentRetrievalStep.java, consent.mgt.extensions/.../Utils.java
Retrieves additionalDisplayData from response and propagates it into the authorization screen context. Appends response data as JSONArray under ADDITIONAL_DISPLAY_DATA constant and extracts sections to attributeMap under ADDITIONAL_DISPLAY_SECTION_TAG.
Additional Display Data UI Rendering
authentication.endpoint/.../fs_default_account_selection.jsp, authentication.endpoint/.../custom-common.css, authentication.endpoint/.../tooltip-functions.js
JSP iterates additional sections rendering separators, headings, and display lists. CSS adds .hide, .popover, and popover content styling. New JavaScript module initializes Bootstrap popovers for unavailable account indicators with hover/focus triggers.
Response Payload Signing Configuration
financial-services.xml, financial-services.xml.j2, common/...FinancialServicesConstants.java, common/...FinancialServicesConfigParser.java, consent.mgt.endpoint/.../ConsentUtils.java
Adds new configuration element ResponsePayloadSigning with default value false. New constant CONSENT_RESPONSE_PAYLOAD_SIGNING and accessor method in parser. New utility method isResponsePayloadSigningEnabled() to parse and return boolean config value.
Response Payload Signing Validation Logic
consent.mgt.endpoint/...ConsentValidationEndpoint.java
Conditionally signs consent payload based on isResponsePayloadSigningEnabled() check. If disabled, raw payload is inserted; if enabled, payload is signed with default key before insertion.
Bug Fixes & Refactoring
authentication.endpoint/.../auth-functions.js, consent.mgt.dao/...ConsentManagementDAOUtil.java, common-mediation-policies/.../ConsentEnforcementPayloadMediator.java
Fixes variable name from standaloneAccount.length to standaloneAccounts.length for proper NodeList length check. Reformats method signature in DAO utility for readability. Adjusts indentation in payload mediator with no functional change.

Sequence Diagram(s)

sequenceDiagram
    participant AuthStep as ExternalAPIConsentRetrievalStep
    participant DTO as PopulateConsentAuthorizeScreenDTO
    participant Util as Utils
    participant JSP as fs_default_account_selection.jsp
    participant UI as Browser/UI
    
    AuthStep->>AuthStep: Retrieve response with additionalDisplayData
    AuthStep->>DTO: Set additionalDisplayData field
    Util->>Util: Extract ADDITIONAL_DISPLAY_DATA from dataSetMap
    Util->>Util: Store under ADDITIONAL_DISPLAY_SECTION_TAG
    DTO->>JSP: Pass additionalSections in request
    JSP->>JSP: Iterate sections: render heading, subHeading
    JSP->>JSP: Iterate displayList items per section
    JSP->>UI: Render dynamic UI sections with separators
    UI->>UI: Attach tooltip popovers via tooltip-functions.js
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

The changes span multiple cohorts with varying complexity: extensive Javadoc fixes are repetitive and low-effort, but the new feature (additional display data) introduces a new DTO, backend logic, configuration, and UI rendering requiring separate reasoning across multiple layers. The response payload signing feature adds straightforward configuration and conditional logic. Mixed heterogeneity demands attention across frontend and backend components, but individual changes within each layer are self-contained.

Poem

🐰 New sections bloom in autumn's display,
Where signing and tips now brighten the way,
With tooltips that hover and periods precise,
The UI now dances—oh, what a device!
From backend to frontend, the data takes flight,
More joy in each click, more features of might!

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 37.74% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check ❓ Inconclusive The PR description covers the main objectives and includes a development checklist with multiple items checked. However, it lacks required sections like Issue link, Doc Issue, and Secure Development Checklist items are incomplete. Add the required Issue link and consider completing the Secure Development Checklist section. Include dependency-check plugin verification if new dependencies were added.
✅ Passed checks (1 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: adding unavailable accounts display in the authorization screen for CDS Toolkit support.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Comment on lines +208 to +209
List<Map<String, Object>> displayData = (List<Map<String, Object>>)
dataSetMap.get(ConsentAuthorizeConstants.DISPLAY_DATA);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Log Improvement Suggestion No: 3

Suggested change
List<Map<String, Object>> displayData = (List<Map<String, Object>>)
dataSetMap.get(ConsentAuthorizeConstants.DISPLAY_DATA);
List<Map<String, Object>> displayData = (List<Map<String, Object>>)
dataSetMap.get(ConsentAuthorizeConstants.DISPLAY_DATA);
if (log.isDebugEnabled()) {
log.debug("Retrieved display data for consent customization with size: " +
(displayData != null ? displayData.size() : 0));
}

Copy link
Contributor

@wso2-engineering wso2-engineering bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Agent Log Improvement Checklist

⚠️ Warning: AI-Generated Review Comments

  • The log-related comments and suggestions in this review were generated by an AI tool to assist with identifying potential improvements. Purpose of reviewing the code for log improvements is to improve the troubleshooting capabilities of our products.
  • Please make sure to manually review and validate all suggestions before applying any changes. Not every code suggestion would make sense or add value to our purpose. Therefore, you have the freedom to decide which of the suggestions are helpful.

✅ Before merging this pull request:

  • Review all AI-generated comments for accuracy and relevance.
  • Complete and verify the table below. We need your feedback to measure the accuracy of these suggestions and the value they add. If you are rejecting a certain code suggestion, please mention the reason briefly in the suggestion for us to capture it.
Comment Accepted (Y/N) Reason
#### Log Improvement Suggestion No: 1
#### Log Improvement Suggestion No: 2
#### Log Improvement Suggestion No: 3

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
financial-services-accelerator/react-apps/self-care-portal/src/main/java/org/wso2/financial/services/accelerator/scp/webapp/service/ResourceInterceptorService.java (1)

159-160: ⚠️ Potential issue | 🟡 Minor

Incorrect null check for optString() return value.

JSONObject.optString() returns an empty string "" when the key is missing, not null. The null check on line 160 will always pass. While this likely works by accident (since containsKey("") returns false), the logic should explicitly check for empty strings.

🔧 Suggested fix
         String clientId = dataElementJson.optString(Constants.CLIENT_ID_CC);
-        if (clientId != null && appClientNameMap.containsKey(clientId)) {
+        if (StringUtils.isNotEmpty(clientId) && appClientNameMap.containsKey(clientId)) {
             dataElementJson.put(Constants.SOFTWARE_CLIENT_NAME, appClientNameMap.get(clientId));
             dataElementJson.put(Constants.LOGO_URL, appLogoUrlMap.get(clientId));
🤖 Fix all issues with AI agents
In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/authorize/model/DisplayDataDTO.java`:
- Around line 1-9: This file is missing the Apache 2.0 license header; add the
same standard Apache-2.0 header used elsewhere in the repo (e.g., the header
from ExternalAPIConsentRetrievalStep.java) immediately above the package
declaration for the DisplayDataDTO class so the top of the file contains the
full copyright/license block consistent with other files.

In
`@financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/fs_default_account_selection.jsp`:
- Around line 127-132: The JSP prints unescaped user input via
record.displayName inside the c:forEach, causing XSS; replace the raw EL output
with the JSTL escape mechanism (use the c:out tag with the record.displayName
value) so the value is HTML-escaped before rendering, and ensure the JSTL core
taglib (prefix c) is declared in the JSP if not already present.
🧹 Nitpick comments (4)
financial-services-accelerator/react-apps/self-care-portal/src/main/java/org/wso2/financial/services/accelerator/scp/webapp/exception/TokenGenerationException.java (1)

24-24: Improve Javadoc sentence structure.

The Javadoc description uses an incomplete sentence. "Throws if errors occurred..." should be revised to follow standard exception class documentation conventions using passive voice and consistent tense.

📝 Suggested Javadoc improvement
-* Throws if errors occurred during the request forwarding process.
+* Thrown when errors occur during the request forwarding process.
financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.service/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/service/ConsentCoreService.java (1)

766-774: Consider completing the Javadoc documentation.

The Javadoc has incomplete parameter, return, and exception descriptions. Additionally, there are minor grammar issues: "consents which has" should be "consents which have" and "a expiring" should be "an expiring".

📝 Proposed Javadoc improvement
 /**
- * This method is used to fetch consents which has a expiring time as a consent attribute.
- * (eligible for expiration)
- * `@param` statusesEligibleForExpiration
- * `@return`
- * `@throws` ConsentManagementException
+ * This method is used to fetch consents which have an expiring time as a consent attribute
+ * and are eligible for expiration.
+ *
+ * `@param` statusesEligibleForExpiration the consent statuses that are eligible for expiration
+ * `@return` a list of detailed consent resources eligible for expiration
+ * `@throws` ConsentManagementException if an error occurs while retrieving the consents
  */
financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/authorize/impl/ExternalAPIConsentRetrievalStep.java (1)

161-169: Consider checking for empty display data before adding to JSON.

The current implementation adds an empty JSONArray to the response when displayData is non-null but contains no items. Consider adding an emptiness check for consistency with how the UI handles this data (the JSP checks not empty displayData).

♻️ Suggested refinement
             // Append display data, if exists, to json object
-            if (responseDTO.getDisplayData() != null) {
+            if (responseDTO.getDisplayData() != null &&
+                    responseDTO.getDisplayData().getDisplayData() != null &&
+                    !responseDTO.getDisplayData().getDisplayData().isEmpty()) {
                 jsonObject.put(
                         ConsentAuthorizeConstants.DISPLAY_DATA,
                         new JSONArray(responseDTO.getDisplayData().getDisplayData())
                 );
             }
-
financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/fs_default_account_selection.jsp (1)

99-120: Hardcoded UI strings limit internationalization.

The text content ("Accounts Unavailable To Share", explanation text, "Why can't I share these?") is hardcoded in English. Other strings in this file are passed via session attributes (e.g., ${buttonNext}, ${appRequestsDetails}). Consider externalizing these strings for consistency and i18n support.

Comment on lines +127 to +132
<c:forEach var="record" items="${displayData}">
<label>
${record.displayName}
</label>
<br/>
</c:forEach>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

XSS vulnerability: Escape user-facing output.

${record.displayName} is rendered without escaping. If displayName contains HTML or JavaScript, it will be executed in the user's browser. Use <c:out> to safely escape the value.

🔒 Proposed fix
                                                 <c:forEach var="record" items="${displayData}">
                                                     <label>
-                                                        ${record.displayName}
+                                                        <c:out value="${record.displayName}"/>
                                                     </label>
                                                     <br/>
                                                 </c:forEach>
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
<c:forEach var="record" items="${displayData}">
<label>
${record.displayName}
</label>
<br/>
</c:forEach>
<c:forEach var="record" items="${displayData}">
<label>
<c:out value="${record.displayName}"/>
</label>
<br/>
</c:forEach>
🤖 Prompt for AI Agents
In
`@financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/fs_default_account_selection.jsp`
around lines 127 - 132, The JSP prints unescaped user input via
record.displayName inside the c:forEach, causing XSS; replace the raw EL output
with the JSTL escape mechanism (use the c:out tag with the record.displayName
value) so the value is HTML-escaped before rendering, and ensure the JSTL core
taglib (prefix c) is declared in the JSP if not already present.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 8

🤖 Fix all issues with AI agents
In
`@financial-services-accelerator/common-mediation-policies/consent-enforcement/consent-enforcement-payload-mediator/pom.xml`:
- Line 111: The coverage minimum in the consent-enforcement-payload-mediator
pom.xml was lowered to 0.7 and should either be restored to 0.8 and supplemented
with tests or the rationale recorded; restore the <minimum> value back to 0.80
in the pom.xml for the consent-enforcement-payload-mediator module and add unit
tests exercising the new code paths to meet the original gate, or if you intend
to keep 0.7 permanently, add a clear justification in the PR description or
commit message referencing the consent-enforcement-payload-mediator module and
the coverage change so future maintainers understand why the threshold was
lowered.

In
`@financial-services-accelerator/common-mediation-policies/consent-enforcement/consent-enforcement-payload-mediator/src/main/java/org/wso2/financial/services/apim/mediation/policies/consent/enforcement/constants/ConsentEnforcementConstants.java`:
- Line 45: The DOMS_ENABLED constant in ConsentEnforcementConstants
(ConsentEnforcementConstants.DOMS_ENABLED) is defined as an empty string and
unused; either remove this unused constant or set it to the proper configuration
key string consistent with other "Configs" entries (e.g., the actual DOMS config
path in your environment) and update any code that should reference it to use
ConsentEnforcementConstants.DOMS_ENABLED; locate the constant in the
ConsentEnforcementConstants class and delete it if not needed, or replace the
empty value with the correct config key and run a search to replace any
hardcoded strings to reference this constant.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/authorize/model/DisplayDataInnerItemDTO.java`:
- Around line 79-82: The addItem method in DisplayDataInnerItemDTO currently
adds the provided Map to displayList without validating it, which allows a null
entry to be stored and later cause NPEs; update the addItem(Map<String, Object>
item) method to first validate that item is not null (e.g., if (item == null)
throw new IllegalArgumentException("item cannot be null")) and also ensure the
displayList field is initialized before adding (initialize displayList if null),
so callers either get a clear exception for invalid input or the item is safely
added.
- Around line 1-14: This file is missing the standard Apache 2.0 license header;
add the project's canonical license comment block (including copyright owner and
Apache 2.0 terms) directly above the package declaration in the
DisplayDataInnerItemDTO class file so it matches other files in the repo (ensure
the header appears before "package
org.wso2.financial.services.accelerator.consent.mgt.extensions.authorize.model;"
and preserve the existing imports and class declaration).

In
`@financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/fs_default_account_selection.jsp`:
- Line 99: The HTML uses a static id "UnavailableAccountPopover" inside the
<c:forEach> loop which creates duplicate ids; update the id generation inside
the loop (the element with id "UnavailableAccountPopover") to include a unique
suffix (for example using the loop index or a unique account identifier like
${status.index} or ${account.id}) and update any JS that queries it
(document.getElementById or selectors) to use the same constructed id so each
iteration yields a unique id and lookups remain correct.
- Around line 105-107: The element id "unavailablePopoverContentElement" is
declared inside the loop and will be duplicated; change it to produce unique
identifiers per iteration or use a class plus a data attribute instead so
tooltip JS can target each instance. Specifically, update the JSP output for the
anchor with id "unavailablePopoverContentElement" to either append the loop
index (from the loop variable or c:forEach varStatus) to the id (e.g.,
unavailablePopoverContentElement_${status.index}) or replace the id with a class
(e.g., unavailablePopoverContentElement) and a unique data attribute (e.g.,
data-section="${section.id}") and then update the tooltip initialization code to
select by that class/data attribute.
- Around line 88-119: The EL outputs in the JSP (section.heading,
section.subHeading, section.description, record.displayName) are rendered
unescaped and pose an XSS risk; update the fs_default_account_selection.jsp to
render these user-facing values using JSTL escaping (replace raw EL like
${section.heading} etc. with <c:out value="${section.heading}" /> and similarly
for ${section.subHeading}, ${section.description}, and ${record.displayName}) so
external API content is HTML-escaped before insertion into the DOM.

In
`@financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.consent.mgt.endpoint/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/endpoint/api/ConsentValidationEndpoint.java`:
- Around line 202-208: ConsentValidationEndpoint currently puts raw JSON into
responsePayload under ConsentExtensionConstants.CONSENT_INFO when
ConsentUtils.isCdsDeploymentEnabled() is true, but downstream
PaymentService.getRequest() and VrpService.getRequest() expect a JWT (three
dot-separated segments); change the endpoint to always send a signed JWT: call
ConsentUtils.signJWTWithDefaultKey(consentInfoPayload) for both branches (i.e.,
remove or bypass the raw JSON branch) so CONSENT_INFO is always a JWT, ensuring
compatibility with the existing getRequest() parsing logic in PaymentService and
VrpService.
🧹 Nitpick comments (1)
financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.consent.mgt.endpoint/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/endpoint/api/ConsentValidationEndpoint.java (1)

209-212: Misleading error message when CDS deployment is enabled.

The catch block logs "Error occurred while getting private key", but when CDS deployment is enabled, no private key retrieval occurs. If generatePayload() throws, this message would be confusing in logs. Consider a more generic error message.

Suggested improvement
         } catch (Exception e) {
-            log.error("Error occurred while getting private key", e);
-            throw new ConsentException(ResponseStatus.INTERNAL_SERVER_ERROR, "Error while getting private key");
+            log.error("Error occurred while building consent validation response payload", e);
+            throw new ConsentException(ResponseStatus.INTERNAL_SERVER_ERROR,
+                    "Error while building consent validation response");
         }

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Fix all issues with AI agents
In
`@financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/js/tooltip-functions.js`:
- Around line 1-6: The current code calls $(document).ready) and does element
lookups into $infoIcon and $hiddenContent before checking that $/jQuery exists,
which will throw if jQuery is missing; to fix, first verify window.jQuery (or $)
is defined and that $.fn.popover is a function, then inside that guard call
$(document).ready and perform the element lookups for
'#unavailablePopoverContentElement' and '#UnavailableAccountPopover' and proceed
only if those jQuery selections have length; adjust the logic around the
existing symbols $(document).ready, $.fn.popover, $infoIcon and $hiddenContent
so no $() is invoked unless $ is present.
- Around line 8-16: The popover currently uses unescaped HTML from
`#UnavailableAccountPopover` (populated from section.description) and is
initialized with $infoIcon.popover({ html: true, ... }), which allows XSS; fix
by escaping the JSP EL where these values are rendered (wrap
section.description, section.heading, section.subHeading with <c:out
value="${...}" escapeXml="true"/> in fs_default_account_selection.jsp) and/or
stop treating the popover content as raw HTML (remove or set html:false in the
$infoIcon.popover call or ensure the JS uses the escaped text from
`#UnavailableAccountPopover`) so the content is rendered as text not executable
HTML.

@duleepa-a duleepa-a changed the title Changes for CDS DOMS feature Enable Unavailable Account Display in Authorization Screen to Support CDS Toolkit Feb 19, 2026
@duleepa-a duleepa-a changed the title Enable Unavailable Account Display in Authorization Screen to Support CDS Toolkit Enable Unavailable Accounts Display in Authorization Screen to Support CDS Toolkit Feb 19, 2026
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (4)
financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/js/tooltip-functions.js (1)

20-22: Nit: inconsistent indentation on line 21 (return; uses 3 spaces, rest of file uses 4).

♻️ Proposed fix
     if (typeof $ !== 'function') {
-       return;
+        return;
     }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/js/tooltip-functions.js`
around lines 20 - 22, The indentation for the early return inside the
conditional that checks for jQuery ("if (typeof $ !== 'function') { return; }")
is inconsistent; update the whitespace so the "return;" uses the same 4-space
indentation as the rest of the file (align the "return;" to match existing
indentation style within tooltip-functions.js) to keep formatting consistent.
financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/authorize/model/AdditionalDisplayDataDTO.java (2)

52-53: @Valid on List<Map<String, Object>> is a no-op.

Bean validation cascades @Valid to each Map<String, Object> element, but Map itself carries no constraint annotations, so nothing is actually validated. This annotation is misleading and can safely be removed.

♻️ Proposed fix
-    `@Valid`
     private List<Map<String, Object>> displayList = new ArrayList<>();
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/authorize/model/AdditionalDisplayDataDTO.java`
around lines 52 - 53, The `@Valid` on the displayList field in
AdditionalDisplayDataDTO is a no-op because it would cascade validation to each
Map<String,Object> but Map elements have no constraint annotations; remove the
`@Valid` annotation from the displayList declaration (the List<Map<String,
Object>> displayList field in class AdditionalDisplayDataDTO) to avoid
misleading code and keep the field as a plain List initialized to new
ArrayList<>(); if validation of map contents is required later, replace the Map
with a dedicated DTO with constraint annotations and then reintroduce `@Valid` on
the List.

97-100: addItem silently accepts null and the expected map key ("displayText") is an undocumented implicit contract.

The JSP renders ${record.displayText}, meaning callers must populate each item map with key "displayText". This is nowhere documented in the API. Consider either a null-guard or a Javadoc note documenting expected keys.

♻️ Proposed improvement
     /**
      * Convenience method to add a display item.
+     * The item map should contain at minimum a {`@code` "displayText"} key
+     * for rendering in the consent authorization UI.
+     *
+     * `@param` item non-null map of display key-value pairs
+     * `@throws` IllegalArgumentException if item is null
      */
     public AdditionalDisplayDataDTO addItem(Map<String, Object> item) {
+        if (item == null) {
+            throw new IllegalArgumentException("Display item must not be null");
+        }
         this.displayList.add(item);
         return this;
     }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/authorize/model/AdditionalDisplayDataDTO.java`
around lines 97 - 100, The addItem method in AdditionalDisplayDataDTO currently
accepts null and relies on an undocumented implicit key "displayText"; update
the addItem(Map<String,Object> item) implementation to guard against null
(reject null with IllegalArgumentException or ignore) and validate that
item.containsKey("displayText") (throw IllegalArgumentException if missing), or
alternatively add a clear Javadoc on AdditionalDisplayDataDTO.addItem and the
displayList field specifying that each map must contain the "displayText" key
(and any other required keys) and their expected value types so callers and JSP
rendering (${record.displayText}) are explicit about the contract.
financial-services-accelerator/components/org.wso2.financial.services.accelerator.common/src/main/java/org/wso2/financial/services/accelerator/common/constant/FinancialServicesConstants.java (1)

62-62: CONSENT_RESPONSE_PAYLOAD_SIGNING naming is inconsistent with other boolean config constants.

Boolean-flag constants in this class use the IS_ prefix or _ENABLED suffix (e.g., IS_PSU_FEDERATED, IS_CONSENT_PERIODICAL_EXPIRATION_ENABLED, IS_CONSENT_AMENDMENT_HISTORY_ENABLED). Consider renaming to IS_CONSENT_RESPONSE_PAYLOAD_SIGNING_ENABLED for consistency.

♻️ Proposed rename
-    public static final String CONSENT_RESPONSE_PAYLOAD_SIGNING = "Consent.Validation.ResponsePayloadSigning.Enabled";
+    public static final String IS_CONSENT_RESPONSE_PAYLOAD_SIGNING_ENABLED = "Consent.Validation.ResponsePayloadSigning.Enabled";
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.common/src/main/java/org/wso2/financial/services/accelerator/common/constant/FinancialServicesConstants.java`
at line 62, Rename the boolean config constant CONSENT_RESPONSE_PAYLOAD_SIGNING
to IS_CONSENT_RESPONSE_PAYLOAD_SIGNING_ENABLED to match the class convention
(other constants like IS_PSU_FEDERATED,
IS_CONSENT_PERIODICAL_EXPIRATION_ENABLED); update the constant name in
FinancialServicesConstants (replace CONSENT_RESPONSE_PAYLOAD_SIGNING) and
refactor all usages across the codebase to reference
IS_CONSENT_RESPONSE_PAYLOAD_SIGNING_ENABLED to avoid compilation errors and keep
naming consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/fs_default_account_selection.jsp`:
- Line 113: The JSP is referencing the wrong map key: replace uses of
${record.displayText} in fs_default_account_selection.jsp with
${record.displayName} so it matches the backend map keys populated in Utils (and
TestConstants), or alternatively change the backend to populate the
"displayText" key in Utils.java/TestConstants.java; ensure the JSP, Utils (map
population), and TestConstants all use the same key ("displayName" preferred) to
avoid silent rendering failures.

---

Duplicate comments:
In
`@financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/fs_default_account_selection.jsp`:
- Around line 93-116: The JSP outputs from the additionalSections block render
unescaped EL values and can lead to XSS; replace each raw EL usage (e.g.,
${section.heading}, ${section.subHeading}, ${section.description}, the
title="${section.subHeading}", and ${record.displayText}) with JSP escaping
using <c:out value="..."/> (use <c:out value='${section.subHeading}'/> for the
title attribute) so that all user-provided fields are HTML-escaped before
rendering.

In
`@financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/js/tooltip-functions.js`:
- Around line 35-41: The popover is created with html: true and content pulled
from $hiddenContent.html(), which allows unescaped section.description to
execute as HTML; change the popover to use safe text content by setting html:
false and passing $hiddenContent.text() to $infoIcon.popover (or alternatively
ensure the JSP fully escapes section.description before inserting it into
.unavailable-account-popover) so that the popover displays literal text rather
than executing injected markup; locate the $infoIcon.popover call in
tooltip-functions.js and update the html and content usage accordingly.

---

Nitpick comments:
In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.common/src/main/java/org/wso2/financial/services/accelerator/common/constant/FinancialServicesConstants.java`:
- Line 62: Rename the boolean config constant CONSENT_RESPONSE_PAYLOAD_SIGNING
to IS_CONSENT_RESPONSE_PAYLOAD_SIGNING_ENABLED to match the class convention
(other constants like IS_PSU_FEDERATED,
IS_CONSENT_PERIODICAL_EXPIRATION_ENABLED); update the constant name in
FinancialServicesConstants (replace CONSENT_RESPONSE_PAYLOAD_SIGNING) and
refactor all usages across the codebase to reference
IS_CONSENT_RESPONSE_PAYLOAD_SIGNING_ENABLED to avoid compilation errors and keep
naming consistent.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/authorize/model/AdditionalDisplayDataDTO.java`:
- Around line 52-53: The `@Valid` on the displayList field in
AdditionalDisplayDataDTO is a no-op because it would cascade validation to each
Map<String,Object> but Map elements have no constraint annotations; remove the
`@Valid` annotation from the displayList declaration (the List<Map<String,
Object>> displayList field in class AdditionalDisplayDataDTO) to avoid
misleading code and keep the field as a plain List initialized to new
ArrayList<>(); if validation of map contents is required later, replace the Map
with a dedicated DTO with constraint annotations and then reintroduce `@Valid` on
the List.
- Around line 97-100: The addItem method in AdditionalDisplayDataDTO currently
accepts null and relies on an undocumented implicit key "displayText"; update
the addItem(Map<String,Object> item) implementation to guard against null
(reject null with IllegalArgumentException or ignore) and validate that
item.containsKey("displayText") (throw IllegalArgumentException if missing), or
alternatively add a clear Javadoc on AdditionalDisplayDataDTO.addItem and the
displayList field specifying that each map must contain the "displayText" key
(and any other required keys) and their expected value types so callers and JSP
rendering (${record.displayText}) are explicit about the contract.

In
`@financial-services-accelerator/internal-webapps/org.wso2.financial.services.accelerator.authentication.endpoint/src/main/webapp/js/tooltip-functions.js`:
- Around line 20-22: The indentation for the early return inside the conditional
that checks for jQuery ("if (typeof $ !== 'function') { return; }") is
inconsistent; update the whitespace so the "return;" uses the same 4-space
indentation as the rest of the file (align the "return;" to match existing
indentation style within tooltip-functions.js) to keep formatting consistent.

- Extend account model to carry tooltip title and description
- Render tooltip icon and hidden tooltip content for account entries
- Support tooltip content updates for select-based account picker
- Rename generic tooltip content class for reuse across tooltip scenarios
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants