POC sample apps for new iparam structure - #11
Conversation
⛔ Snyk checks have failed. 2 issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
|
![hivel-marco[bot]](https://avatars.githubusercontent.com/in/2836183?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR Complexity Score: 4.8 - Moderate
View Breakdown
- Lines Changed: 727
- Files Changed: 18
- Complexity Added: 16
- Raw Score: 92.54
⚠️ Sensitive Data (PII/ Secrets) Detected
| File | Types | Count | ||||||
|---|---|---|---|---|---|---|---|---|
|
| Line | Type | Preview |
|---|---|---|
| — | PII: Email Address | manideep@chargebee.c... |
sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/test_data/invoice_generated.json
| Line | Type | Preview |
|---|---|---|
| — | PII: Email Address | manideep@chargebee.c... |
sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/types/types.d.ts
| Line | Type | Preview |
|---|---|---|
| 40 | Secret: Secret Keyword | [Secret Keyword] |
Overview
This PR adds two proof-of-concept sample apps demonstrating different strategies for accessing installation parameters (iparams) when using sectioned iparam definitions.
One sample accesses iparams via section-scoped keys, allowing duplicate parameter names across sections, while the other flattens iparams into top-level keys, requiring globally unique parameter names.
Both apps showcase handling invoice_generated events, applying processing and late payment fees based on configured iparams, and include type definitions, local config, and test data.
Key Changes
- Introduces
poc-sample-app-iparam-access-with-section, where iparams are accessed as nested values under section names (e.g.,payload.iparams.processing_fee_configuration.fee_percentage), explicitly supporting duplicate parameter names across sections. - Introduces
poc-sample-app-with-direct-iparam-access, where iparams are read as flat keys (e.g.,payload.iparams.processing_fee_percentage), illustrating a model where parameter names must be unique across the app. - Adds handler logic in both apps to compute and apply processing fees (with a cap) and late payment fees for
invoice_generatedevents, reading percentages and limits from iparams. - Provides type definitions (
types.d.ts) for event payloads and iparam structures for each app, aligning with the differing iparam access patterns (sectioned vs flat). - Supplies local configuration files (
iparams.local.json), JS config (jsconfig.json), manifests, environment variable templates (.env), and exampleinvoice_generatedevent payloads for testing.
Risks & Considerations
- Divergent iparam typing between the two apps (
iparamsas sectioned vs flat) may cause confusion if samples are reused or combined without care. - The handlers assume specific iparam shapes and presence; missing or malformed iparams could cause runtime
NaNcomputations if not validated before use. - Test event data has invoices with
status: "paid"andtotal: 0, so fee paths may not be exercised unless test data or logic is adjusted. - None of the handlers currently implement the body of
applyAdditionalFee, so downstream integrators must ensure actual mutation/side effects are correctly implemented.
File-level change summary
| File | Change summary |
|---|---|
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/.env | Adds environment variable template for read-only/read-write API keys and site domain for the section-based iparam sample app. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/README.md | Documents the section-based iparam access pattern, including example handler usage, iparams.local.json, and guidance on duplicate parameter names. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/handler/handler.js | Implements the invoiceGeneratedHandler that reads fee configuration from section-scoped iparams and computes/apply additional invoice fees. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/iparams.json | Defines installation parameters grouped into processing_fee_configuration and late_payment_fee_configuration sections with shared parameter names like fee_percentage. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/iparams.local.json | Provides local values for processing and late payment fee configuration using section-scoped keys matching iparams.json. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/jsconfig.json | Configures JavaScript compiler options and path aliases for the section-based iparam sample app. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/manifest.json | Declares the invoice_generated event mapping to the invoiceGeneratedHandler for the section-based sample. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/test_data/invoice_generated.json | Adds a sample invoice_generated event payload for testing the section-based handler. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/types/types.d.ts | Introduces TypeScript definitions for event records, section-based iparam inputs, and handler payloads for the section-based app. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/.env | Adds environment variable template for read-only/read-write API keys and site domain for the direct iparam access sample app. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/README.md | Documents the direct (flat) iparam access pattern, including example handler usage, iparams.local.json, and note that duplicate names are not allowed. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/handler/handler.js | Implements the invoiceGeneratedHandler that reads fee configuration from flat iparam keys and computes/apply additional invoice fees. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/iparams.json | Defines installation parameters in sections but with globally unique parameter names that are read as flat iparam keys. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/iparams.local.json | Provides local values for flat processing and late payment fee parameters matching the handler’s expected key names. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/jsconfig.json | Configures JavaScript compiler options and path aliases for the direct iparam access sample app. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/manifest.json | Declares the invoice_generated event mapping to the invoiceGeneratedHandler for the direct-access sample. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/test_data/invoice_generated.json | Adds a sample invoice_generated event payload for testing the direct-access handler. |
| sample-apps/iparams-new-structure-with-groups/poc-sample-app-with-direct-iparam-access/types/types.d.ts | Introduces TypeScript definitions for event records, flat iparam inputs, and handler payloads for the direct-access app. |
| const processingFeePercentage = Number(payload.iparams.processing_fee_percentage); | ||
| const processingFeeLimit = Number(payload.iparams.processing_fee_limit); | ||
| const latePaymentFeePercentage = Number(payload.iparams.late_payment_fee_percentage); | ||
|
|
||
| const isUnpaid = invoice.status !== 'paid'; | ||
| const hasChargeableTotal = invoice.total > 0; | ||
| const isPastDue = invoice.due_date < payload.event.occurred_at; |
There was a problem hiding this comment.
Priority: 🟠 HIGH
Problem: Installation parameter values are coerced with Number(...) and used directly without any validation, so missing or non-numeric iparams will propagate NaN into fee calculations and eventually into applyAdditionalFee.
Why: If any of processing_fee_percentage, processing_fee_limit, or late_payment_fee_percentage is undefined or not a valid number, Number() returns NaN; this causes calculateAdditionalFee and Math.min to return NaN, leading to incorrect or invalid fee amounts being applied at runtime.
How to Fix: After converting the iparams to numbers, explicitly validate that they are finite numeric values and bail out early if they are not, preventing NaN values from entering the fee calculation logic.
| const processingFeePercentage = Number(payload.iparams.processing_fee_percentage); | |
| const processingFeeLimit = Number(payload.iparams.processing_fee_limit); | |
| const latePaymentFeePercentage = Number(payload.iparams.late_payment_fee_percentage); | |
| const isUnpaid = invoice.status !== 'paid'; | |
| const hasChargeableTotal = invoice.total > 0; | |
| const isPastDue = invoice.due_date < payload.event.occurred_at; | |
| const processingFeePercentage = Number(payload.iparams.processing_fee_percentage); | |
| const processingFeeLimit = Number(payload.iparams.processing_fee_limit); | |
| const latePaymentFeePercentage = Number(payload.iparams.late_payment_fee_percentage); | |
| if ( | |
| !Number.isFinite(processingFeePercentage) || | |
| !Number.isFinite(processingFeeLimit) || | |
| !Number.isFinite(latePaymentFeePercentage) | |
| ) { | |
| return; | |
| } | |
| const isUnpaid = invoice.status !== 'paid'; | |
| const hasChargeableTotal = invoice.total > 0; | |
| const isPastDue = invoice.due_date < payload.event.occurred_at; |
| "source": "admin_console", | ||
| "user": "manideep@chargebee.com", | ||
| "webhook_status": "scheduled", |
There was a problem hiding this comment.
Priority: 🟠 HIGH
Problem: The user field contains what appears to be a real email address ("manideep@chargebee.com"), which introduces unnecessary personally identifiable information (PII) into the repository.
Why: Shipping real or potentially real user/staff email addresses in version control is a privacy and security risk and can lead to unsolicited contact or data exposure; sample payloads should use clearly fictitious, non-identifiable values instead.
How to Fix: Replace the real-looking email address with an obviously dummy/test email (e.g., using example.com) while preserving the payload structure.
| "source": "admin_console", | |
| "user": "manideep@chargebee.com", | |
| "webhook_status": "scheduled", | |
| "source": "admin_console", | |
| "user": "user@example.com", | |
| "webhook_status": "scheduled", |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (18)
WalkthroughAdds two proof-of-concept sample apps for invoice fee processing: one reads iParams through section names, while the other reads flattened parameter keys. Both include schemas, handlers, manifests, local configurations, types, fixtures, tooling, and documentation. ChangesSection-scoped iParam access
Direct iParam access
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 1✅ Passed checks (1 passed)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8)sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/iparams.jsonTraceback (most recent call last): sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/iparams.local.jsonTraceback (most recent call last): sample-apps/iparams-new-structure-with-groups/poc-sample-app-iparam-access-with-section/jsconfig.jsonTraceback (most recent call last):
Comment |
![snyk-io[bot]](https://avatars.githubusercontent.com/in/372950?s=60&v=4){kind=small}
| "webhook_status": "scheduled", | ||
| "webhooks": [ | ||
| { | ||
| "id": "whv2_AzZX7CUVnj5rB1ZHq", |
There was a problem hiding this comment.
Detected a generic secret, which could lead to unauthorized access and sensitive data exposure.
CWE-798: Generic Secret Key | Learn more about this vulnerability
Details and remediation
Why this is dangerous
Attackers can discover hardcoded credentials in source code to gain unauthorized access, escalate privileges, steal data, or disrupt services. If you reuse credentials across systems or environments, the impact increases.
Immediate action
- Treat hardcoded credentials as compromised.
- Remove the credentials from the code.
- Rotate or revoke the credential and update all affected systems.
- Store the new secret in a secrets manager or vault, or inject the secret using environment variables at runtime.
Preventing future exposure
- Do not hardcode secrets.
- Use pre-commit hooks and automated secrets scanning to prevent accidental commits.
- Use secrets management tools, such as vaulting, environment injection, or secure configuration.
- Use least-privilege credentials and strong salted hashes for stored passwords.
- Add secure authentication practices to the development workflow.
You can view, fix, and ignore this issue in the Snyk Web UI
| "webhook_status": "scheduled", | ||
| "webhooks": [ | ||
| { | ||
| "id": "whv2_AzZX7CUVnj5rB1ZHq", |
There was a problem hiding this comment.
Detected a generic secret, which could lead to unauthorized access and sensitive data exposure.
CWE-798: Generic Secret Key | Learn more about this vulnerability
Details and remediation
Why this is dangerous
Attackers can discover hardcoded credentials in source code to gain unauthorized access, escalate privileges, steal data, or disrupt services. If you reuse credentials across systems or environments, the impact increases.
Immediate action
- Treat hardcoded credentials as compromised.
- Remove the credentials from the code.
- Rotate or revoke the credential and update all affected systems.
- Store the new secret in a secrets manager or vault, or inject the secret using environment variables at runtime.
Preventing future exposure
- Do not hardcode secrets.
- Use pre-commit hooks and automated secrets scanning to prevent accidental commits.
- Use secrets management tools, such as vaulting, environment injection, or secure configuration.
- Use least-privilege credentials and strong salted hashes for stored passwords.
- Add secure authentication practices to the development workflow.
You can view, fix, and ignore this issue in the Snyk Web UI
|
⛔ PR has more than 250 additions. Split it into smaller PRs. It contains 304 extra lines. |
1 participant
CHANGELOG
REPLACE_ME_WITH_CHANGELOG
SUMMARY
REPLACE_ME_WITH_SUMMARY_OF_THE_CHANGES
FUNCTIONAL AUTOMATION CHANGES PR
AUTOMATION TEST REPORT URL
REPLACE_ME_WITH_TEST_REPORT_URL
AREAS OF IMPACT
REPLACE_ME_WITH_AREAS_OF_IMPACT_OR_NA
TYPE OF CHANGE
DOCUMENTATION
REPLACE_ME_WITH_DOCUMENTATION_LINK_OR_NA
Adds two proof-of-concept sample applications demonstrating grouped iParam configurations: one accesses parameters directly, while the other scopes them by section. Each includes manifests, parameter definitions, handlers for invoice-generated events, local configuration, documentation, type declarations, and test fixtures.