Badly coded websites

Posted Sep 14, 2024 16:27 UTC (Sat) by farnz (subscriber, #17727)
In reply to: Badly coded websites by sammythesnake
Parent article: A SpamAssassin surprise

The trouble is that, while I've encountered cases that are the payment card industry's fault (Amex CV2 being 4 digits and in a different place on the card, some cards having a 19 digit PAN), I've also encountered a lot that add complexity (like "CV2 can't be interpreted as a date in the format M/YY"). And while I get the temptation to simplify in ways that you think don't matter, adding complexity because you assume things outside the spec doesn't make a huge amount of sense to me.

Badly coded websites

Posted Oct 2, 2024 8:22 UTC (Wed) by taladar (subscriber, #68407) [Link] (2 responses)

> "CV2 can't be interpreted as a date in the format M/YY"

Wouldn't that break for the last three months of every year? Not to mention that 4 digit years should really be used for everything by now.

Badly coded websites

Posted Oct 2, 2024 10:12 UTC (Wed) by farnz (subscriber, #17727) [Link]

The CV2 is three digits; I had a CV2 (at the time) of 821, and the site rejected this on the grounds that this "must" be the issue date of my card, not the CV2.

I assume that they were looking at the last 2 digits, and deciding if it looked "too close" to a plausible expiry or issue year in order to determine if the CV2 was valid, but the error message told me that it was rejecting it because I'd supplied the issue date, not the CV2. Experimentally, it also rejected 828 as my card expiry date (even though I had put in the actual expiry date elsewhere in the form).

Badly coded websites

Posted Oct 2, 2024 10:34 UTC (Wed) by Wol (subscriber, #4433) [Link]

Actually, I would have thought it would break for every CV2 >= 100. M can't be 0, but YY could be anything.

And why use YYYY for user interaction when all dates are "about now"? Credit card dates are all within a 10-yr windows, so YY is not ambiguous.

Cheers,
Wol