[PM-39358] fix: Reject partial card scans via Luhn and brand-length validation - #2845
Conversation
…alidation Partial OCR scans could produce digit sequences that matched the card-number regex and were auto-filled despite being incomplete. CardTextParser now rejects any candidate number that fails the Luhn mod-10 checksum or whose digit count does not match the expected length for the detected brand.
🤖 Bitwarden Claude Code ReviewOverall Assessment: APPROVE Reviewed the addition of Luhn mod-10 checksum and brand-specific digit-length validation to Code Review DetailsNo findings. The change is well-scoped, correctly implemented, and appropriately tested. No security concerns (no card data is logged or persisted), no architecture violations, and no breaking changes. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2845 +/- ##
=======================================
Coverage 81.25% 81.25%
=======================================
Files 1028 1028
Lines 66164 66194 +30
=======================================
+ Hits 53761 53788 +27
- Misses 12403 12406 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-39358
📔 Objective
Partial OCR card scans could produce digit sequences that matched the regex in
CardTextParserand were auto-filled into the card-number field despite being incomplete (e.g. the card was not fully in frame). This PR adds two validation layers insideCardTextParser.extractCardNumber(from:):CardComponent.Brandis extended with avalidDigitLengths: Set<Int>property that drives the length check.No UI changes; scanner behaviour is unchanged from the user's perspective — the form simply never populates from an invalid number.