[CUS-12595] created add-on for filtering values from the response body.#388
[CUS-12595] created add-on for filtering values from the response body.#388ManojTestsigma wants to merge 1 commit into
Conversation
|
|
📝 WalkthroughWalkthroughThis PR introduces a new Maven module ChangesCustomised API Actions Module
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the 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: 8
🧹 Nitpick comments (1)
customised_api_actions/pom.xml (1)
53-63: ⚡ Quick winConsider using
<scope>provided</scope>forselenium-javaandjava-clientif this addon is shaded locally before upload.The Testsigma runtime classpath does provide Selenium 4.33.0 and Appium java-client 9.4.0, so these don't need to be bundled into the addon JAR. However, official Testsigma addon samples use compile scope by default. Mark these as provided only if: (1) the addon is built locally with the Shade Plugin into an uber JAR before upload, and (2) Testsigma confirms the upload process doesn't require bundled dependencies. Otherwise, keep them as compile scope per Testsigma's published examples.
🤖 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 `@customised_api_actions/pom.xml` around lines 53 - 63, The pom currently declares selenium-java and io.appium:java-client as regular compile dependencies; if you build an uber JAR with the Shade plugin and Testsigma confirms uploaded addons need not bundle these libs, change the selenium-java and java-client dependency entries (artifactId "selenium-java" and "java-client") to use <scope>provided</scope> so they are not packaged into the addon JAR; if you are NOT shading locally or Testsigma requires bundled deps, leave them as compile scope per the official examples.
🤖 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 `@customised_api_actions/pom.xml`:
- Around line 47-51: The TestNG dependency (groupId org.testng, artifactId
testng) lacks a test scope and will be packaged into the shaded JAR; update the
pom so that the testng dependency includes <scope>test</scope> (same pattern
used for junit-jupiter-api) to ensure it is only used for tests and not bundled
into customised_api_actions.jar.
- Line 24: The pom defines <jackson.version>2.13.0</jackson.version> which is
vulnerable; update the jackson-databind version to a safe release (e.g., set
jackson.version to 2.21.2 or at minimum >= 2.13.4.2) and ensure any direct
dependencies that reference jackson-databind (e.g., dependencies or
dependencyManagement entries) use that property or are updated accordingly;
after changing the jackson.version property, run your build (mvn -U package) or
mvn dependency:tree to verify no transitive dependency pins an older
jackson-databind and bump those artifacts or add an explicit
dependencyManagement override if needed.
In `@customised_api_actions/src/main/java/com/testsigma/addons/web/Api` inputs:
- Around line 116-129: Remove the duplicated table block under the "Pattern for
remaining sections" heading: keep the second occurrence and delete the earlier
redundant header and the first table rows for Section ID 4 and 5 (the repeated
rows containing {"pageId":6,"sectionId":4,"isReqSection":0} -> section4Fields
and {"pageId":6,"sectionId":5,"isReqSection":0} -> section5Fields); ensure only
one "Pattern for remaining sections" block with the correct header and rows
remains.
- Line 14: The file contains a committed real credential string in the
request-payload (username "jalalhussain@truemedit.com" and password
"Test@12345"); rotate the password for that account immediately, remove the
plaintext credentials from the payload and replace them with non-sensitive
placeholders (e.g. "REDACTED_USERNAME", "REDACTED_PASSWORD") wherever the
request-payload appears, and update any tests or docs to use environment
variables or secrets management instead of hardcoded values; if this branch was
pushed publicly, scrub the secret from Git history using a tool like git
filter-repo (or BFG) and follow your org’s incident/credential-rotation
checklist.
In
`@customised_api_actions/src/main/java/com/testsigma/addons/web/CustomisedApiCall.java`:
- Around line 264-284: parseCriteria currently splits the criteria string on
every comma which breaks values containing commas (e.g., "label=Foo,Bar");
update parseCriteria to parse on commas only when not inside quotes or when not
escaped (or use a small CSV/tokenizer) so values like label="Foo,Bar" or
label=Foo\,Bar are preserved as one rule, keep the current trimming/validation
and logger messages, and also update the action annotation/docs to mention that
quoted or escaped commas are supported (or require quoting/escaping) so users
know how to provide comma-containing values.
- Around line 204-208: The code in CustomisedApiCall currently logs the full
HTTP response body on non-2xx responses (logger.warn and RuntimeException
construction), which may expose PII or bearer tokens; replace direct uses of
response.body() with a sanitized/truncated value: implement a helper like
sanitizeResponseBody(String body) or maskSensitiveData(String body) and use it
in both logger.warn and the exception message (e.g., log either "[REDACTED]" or
the first N chars + "...(truncated)" and do not include tokens or known JSON
fields like "access_token"), ensuring the logger still indicates there was a
body but never emits the full raw body.
- Around line 152-198: The HttpClient is created with HttpClient.newHttpClient()
which has no connect/read timeouts and can block indefinitely at
client.send(...); update CustomisedApiCall to build the client with timeouts
(use HttpClient.newBuilder().connectTimeout(...) and set a request timeout via
HttpRequest.Builder.timeout(...)) and make the timeout value configurable (e.g.,
a default like 30s but read from configuration/params). Ensure you replace the
HttpClient client = HttpClient.newHttpClient() with a builder-based client using
the configured Duration and add builder.timeout(Duration) before
client.send(...) so both connect and overall request timeouts are enforced.
In `@customised_api_actions/src/main/resources/testsigma-sdk.properties`:
- Line 1: The committed live JWT value for the property testsigma-sdk.api.key
must be rotated and removed: immediately revoke/rotate the exposed API key in
the Testsigma console, replace the value in testsigma-sdk.properties with a
placeholder (e.g. TESTSIGMA_API_KEY_PLACEHOLDER) before committing, and add
testsigma-sdk.properties to .gitignore (or update README to require developers
to create a local copy) so real keys are never committed again; ensure any
CI/secrets storage is updated to use the new rotated key.
---
Nitpick comments:
In `@customised_api_actions/pom.xml`:
- Around line 53-63: The pom currently declares selenium-java and
io.appium:java-client as regular compile dependencies; if you build an uber JAR
with the Shade plugin and Testsigma confirms uploaded addons need not bundle
these libs, change the selenium-java and java-client dependency entries
(artifactId "selenium-java" and "java-client") to use <scope>provided</scope> so
they are not packaged into the addon JAR; if you are NOT shading locally or
Testsigma requires bundled deps, leave them as compile scope per the official
examples.
🪄 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
Run ID: 7327345b-3b4f-4136-9a7c-7cd1bc6b55f0
📒 Files selected for processing (4)
customised_api_actions/pom.xmlcustomised_api_actions/src/main/java/com/testsigma/addons/web/Api inputscustomised_api_actions/src/main/java/com/testsigma/addons/web/CustomisedApiCall.javacustomised_api_actions/src/main/resources/testsigma-sdk.properties
| <testng.version>7.10.2</testng.version> | ||
| <selenium.version>4.33.0</selenium.version> | ||
| <appium.java.client.version>9.4.0</appium.java.client.version> | ||
| <jackson.version>2.13.0</jackson.version> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
CVE-2022-42003 jackson-databind affected versions
💡 Result:
The affected versions of FasterXML jackson-databind for CVE-2022-42003 are all versions before 2.12.17.1 in the 2.12.x series, before 2.13.4.1 (or more precisely 2.13.4.2 to avoid a Gradle BOM issue) in the 2.13.x series, and before 2.14.0 in the 2.14.x series. This corresponds to approximately >=2.4.0-rc1 and <2.12.17.1 for the 2.12 branch, >=2.13.0 and <2.13.4.2 for the 2.13 branch, and <2.14.0 overall [1][2][3][4]. The vulnerability allows resource exhaustion (DoS) due to deep wrapper array nesting in primitive deserializers when UNWRAP_SINGLE_VALUE_ARRAYS is enabled, fixed by adding depth checks in patches like commit cd09097 [1][5][2][6][3]. Official fix releases are jackson-databind 2.12.17.1, 2.13.4.1/2.13.4.2, and 2.14.0+ [1][2][3][4]. NVD CPE confirms versions up to but excluding these fixes [1][7].
Citations:
- 1: https://nvd.nist.gov/vuln/detail/cve-2022-42003
- 2: GHSA-jjjh-jjxp-wpff
- 3: https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.12
- 4: https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.13
- 5: https://www.sentinelone.com/vulnerability-database/cve-2022-42003/
- 6: https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.13.4/release-notes/VERSION-2.x
- 7: https://nvd.nist.gov/vuln/detail/CVE-2022-42003
🌐 Web query:
jackson-databind 2.13.0 security vulnerabilities CVEs
💡 Result:
Jackson-databind version 2.13.0 has several known security vulnerabilities, primarily denial-of-service (DoS) issues. The key CVEs affecting this exact version include: - CVE-2022-42003: Resource exhaustion due to lack of check in primitive value deserializers for deep wrapper array nesting when UNWRAP_SINGLE_VALUE_ARRAYS is enabled. Affected: [2.13.0, 2.13.4.1). Fixed in 2.13.4.1.[1][2][3] - CVE-2022-42004: Resource exhaustion in BeanDeserializer._deserializeFromArray due to deeply nested arrays (requires specific deserialization config). Affected: [2.13.0, 2.13.4). Fixed in 2.13.4.[1][4] - CVE-2020-36518: Java StackOverflowError from deeply nested objects. Affected: [2.13.0, 2.13.2.1). Fixed in 2.13.2.1.[1][5][6] - CVE-2021-46877: DoS via 2GB transient heap usage in JsonNode JDK serialization (uncommon). Affected: 2.13.0 (prior to 2.13.1).[7][8] Older gadget deserialization CVEs (e.g., CVE-2018-*) do not affect 2.13.0 as they were fixed in earlier versions.[1] No new CVEs post-2022 appear to affect 2.13.0 based on sources up to 2026.[9][10] Recommendation: Upgrade to at least 2.13.4.2 or later (ideally 2.17+ for all fixes). Disable unsafe deserialization features if possible.[11][12][13]
Citations:
- 1: https://repology.org/project/jackson-databind/cves?version=2.13.4.1
- 2: https://advisories.gitlab.com/pkg/maven/com.fasterxml.jackson.core/jackson-databind/CVE-2022-42003
- 3: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-42003
- 4: https://nvd.nist.gov/vuln/detail/cve-2022-42004
- 5: https://www.sentinelone.com/vulnerability-database/cve-2020-36518/
- 6: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-36518
- 7: https://nvd.nist.gov/vuln/detail/cve-2021-46877
- 8: https://vulmon.com/searchpage?q=Fasterxml+Jackson-databind+2.13.0&scoretype=cvssv4&sortby=bydate
- 9: https://www.herodevs.com/blog-posts/cve-2025-52999-denial-of-service-via-stack-overflow-in-jackson-core
- 10: https://security.snyk.io/package/maven/com.fasterxml.jackson.core%3Ajackson-databind
- 11: https://security.snyk.io/package/maven/com.fasterxml.jackson.core%3Ajackson-databind/2.13.0
- 12: https://security.snyk.io/package/maven/com.fasterxml.jackson.core%3Ajackson-databind/2.13.2
- 13: https://advisories.gitlab.com/pkg/maven/com.fasterxml.jackson.core/jackson-databind
🌐 Web query:
jackson-databind latest stable version 2024 2025
💡 Result:
The latest stable version of jackson-databind (com.fasterxml.jackson.core:jackson-databind) as of 2026-05-07 is 2.21.2, released on March 20, 2026 [1][2]. This is confirmed by Maven Repository listing it as the top version in 2.21.x series [1], GitHub tags showing jackson-databind-2.21.2 [3], and other sources like Sonatype Guide and Libraries.io referencing it [2][4]. For the 2.x series (still actively maintained), 2.21 is an LTS branch with ongoing patches [5][6]. Note that Jackson 3.x exists (e.g., 3.1.3 tagged [3]), but uses groupId tools.jackson.core and the query focuses on the traditional 2.x databind [7][8]. In 2024-2025, versions progressed from 2.17.3 (Nov 2024) [1], 2.18.4 (May 2025) [9], 2.19.4 (Oct 2025), to 2.20.2 (Jan 2026), then 2.21.2 [1]. Use Maven dependency: <dependency><groupId>com.fasterxml.jackson.core</groupId><artifactId>jackson-databind</artifactId><version>2.21.2</version></dependency> [10][11].
Citations:
- 1: https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind
- 2: https://guide.sonatype.com/component/maven/com.fasterxml.jackson.core:jackson-databind/2.21.2
- 3: https://github.com/FasterXML/jackson-databind/tags
- 4: https://libraries.io/maven/com.fasterxml.jackson.core:jackson-databind
- 5: https://github.com/FasterXML/jackson/wiki/Jackson-Releases
- 6: https://github.com/FasterXML/jackson-databind/wiki
- 7: https://github.com/FasterXML/jackson-databind
- 8: https://github.com/FasterXML/Jackson-databind
- 9: https://central.sonatype.com/artifact/com.fasterxml.jackson.core/jackson-databind
- 10: https://central.sonatype.com/artifact/com.fasterxml.jackson.core/jackson-databind/2.21.0
- 11: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.21.1/
Upgrade jackson-databind 2.13.0 to the latest stable version to address multiple known CVEs.
Jackson-databind 2.13.0 is vulnerable to:
- CVE-2022-42003: Resource exhaustion due to deep wrapper array nesting with
UNWRAP_SINGLE_VALUE_ARRAYSenabled (affects all 2.13.x versions before 2.13.4.2) - CVE-2022-42004: Resource exhaustion in
BeanDeserializer._deserializeFromArrayvia deeply nested arrays (affects 2.13.x before 2.13.4) - CVE-2020-36518: Stack overflow from deeply nested objects (affects 2.13.x before 2.13.2.1)
Upgrade to 2.21.2 or any version ≥ 2.13.4.2.
🔧 Proposed fix
- <jackson.version>2.13.0</jackson.version>
+ <jackson.version>2.21.2</jackson.version>📝 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.
| <jackson.version>2.13.0</jackson.version> | |
| <jackson.version>2.21.2</jackson.version> |
🤖 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 `@customised_api_actions/pom.xml` at line 24, The pom defines
<jackson.version>2.13.0</jackson.version> which is vulnerable; update the
jackson-databind version to a safe release (e.g., set jackson.version to 2.21.2
or at minimum >= 2.13.4.2) and ensure any direct dependencies that reference
jackson-databind (e.g., dependencies or dependencyManagement entries) use that
property or are updated accordingly; after changing the jackson.version
property, run your build (mvn -U package) or mvn dependency:tree to verify no
transitive dependency pins an older jackson-databind and bump those artifacts or
add an explicit dependencyManagement override if needed.
| if (status < 200 || status >= 300) { | ||
| logger.warn("[CustomisedApiCall] Non-2xx response. Status: " + status + ", Body: " + response.body()); | ||
| throw new RuntimeException("API call to '" + endpoint + "' failed with HTTP " + status + | ||
| ". Response body: " + response.body() + | ||
| ". Check the endpoint URL, request payload, and authentication headers."); |
There was a problem hiding this comment.
Full response body is logged at WARN level on non-2xx responses — can expose PII or secrets.
Line 205 writes the raw API response body to the test log unconditionally. In this addon's documented use-case the response to the authentication request (Step 1) contains a bearer token, and other responses may contain patient/medical data. Logging the body defeats the masking done for headers (line 163, 181).
🔧 Proposed fix — truncate or omit the body from logs
- if (status < 200 || status >= 300) {
- logger.warn("[CustomisedApiCall] Non-2xx response. Status: " + status + ", Body: " + response.body());
- throw new RuntimeException("API call to '" + endpoint + "' failed with HTTP " + status +
- ". Response body: " + response.body() +
- ". Check the endpoint URL, request payload, and authentication headers.");
- }
+ if (status < 200 || status >= 300) {
+ String bodySnippet = response.body() != null
+ ? response.body().substring(0, Math.min(100, response.body().length())) + "..."
+ : "(empty)";
+ logger.warn("[CustomisedApiCall] Non-2xx response. Status: " + status);
+ throw new RuntimeException("API call to '" + endpoint + "' failed with HTTP " + status +
+ ". Response body (truncated): " + bodySnippet +
+ ". Check the endpoint URL, request payload, and authentication headers.");
+ }🤖 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
`@customised_api_actions/src/main/java/com/testsigma/addons/web/CustomisedApiCall.java`
around lines 204 - 208, The code in CustomisedApiCall currently logs the full
HTTP response body on non-2xx responses (logger.warn and RuntimeException
construction), which may expose PII or bearer tokens; replace direct uses of
response.body() with a sanitized/truncated value: implement a helper like
sanitizeResponseBody(String body) or maskSensitiveData(String body) and use it
in both logger.warn and the exception message (e.g., log either "[REDACTED]" or
the first N chars + "...(truncated)" and do not include tokens or known JSON
fields like "access_token"), ensuring the logger still indicates there was a
body but never emits the full raw body.
please review this addon and publish as PUBLIC
Addon name : customised_api_actions
Addon accont: https://jarvis.testsigma.com/ui/tenants/2817/addons
Jira: https://testsigma.atlassian.net/browse/CUS-12595
fix
Summary by CodeRabbit
New Features
Documentation