Bug: Payment amount validation accepts malformed numeric strings
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- payments
Research direction
Open packages/account-sdk/src/interface/payment/utils/validation.ts and inspect validateStringAmount(), starting with its parseFloat-based check. Exercise it with the valid and malformed examples listed in the issue, then replace the partial-number validation with strict decimal-string validation. Done means malformed, empty, zero, negative, and over-precision values are rejected before payment encoding, while the valid examples pass.
Written by the indexing model from the issue text.
Description
Describe the bug
Payment amount validation accepts malformed numeric strings because validateStringAmount() uses parseFloat(). For example, parseFloat("1abc") returns 1, so the value can pass validation even though it is not a valid decimal amount.
Steps
- Open packages/account-sdk/src/interface/payment/utils/validation.ts
- Check validateStringAmount()
- Notice that it validates the amount using parseFloat(amount)
- Try values like:
- "1abc"
- "1.2.3"
- "1foo"
- These values can pass the initial numeric validation because parseFloat() accepts partial numeric strings
- Later, the same value is passed toward payment encoding, where parseUnits() expects a valid decimal string
Expected behavior
validateStringAmount() should reject malformed decimal strings immediately.
Valid examples should include:
- "1"
- "1.0"
- "1.000001"
- "10.50"
Invalid examples should include:
- "1abc"
- "1.2.3"
- "1foo"
- "abc"
- ""
- "."
- "1."
- "0"
- "-1"
Version
2.5.6 / latest master
Additional info
Suggested fix: replace parseFloat-based validation with strict decimal string validation.
Example:
export function validateStringAmount(amount: string, maxDecimals: number): void {
if (typeof amount !== 'string') {
throw new Error('Invalid amount: must be a string');
}
const pattern = new RegExp(`^(?:0|[1-9]\\d*)(?:\\.\\d{1,${maxDecimals}})?$`);
if (!pattern.test(amount)) {
throw new Error(
`Invalid amount: must be a positive decimal string with up to ${maxDecimals} decimal places`
);
}
if (Number(amount) <= 0) {
throw new Error('Invalid amount: must be greater than 0');
}
}
This would make SDK validation stricter and fail earlier with a clear error.
Desktop
- OS: N/A
- Browser: N/A
- Version: N/A
Smartphone
- Device: N/A
- OS: N/A
- Browser: N/A
- Version: N/A
- Dominant language
- TypeScript
- Stars
- 172
- Forks
- 207
- Avg merge
- 49m
- Merged PRs (30d)
- 1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from base/account-sdk
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
base/account-sdk#405 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
base/account-sdk#391 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
base/account-sdk#376 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
base/account-sdk#361 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
base/account-sdk#326 ·
All issues in base/account-sdk
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100