Badly coded websites
Badly coded websites
Posted Sep 14, 2024 11:25 UTC (Sat) by sammythesnake (guest, #17693)In reply to: Badly coded websites by farnz
Parent article: A SpamAssassin surprise
First, the spec is easily found and clearly defined - it's not rocket surgery to get the whole thing right (including knowing if the card is a visa or amex or whatever, so don't ask the user!)
On the other hand, the spec itself is a bear, with 1001 different historical warts, so if you think you find a way to simplify it (which inevitably means being wrong, of course) I can absolutely understand the temptation to do so...
Ideally, the banks etc. would all get together and agree to retire all but one checksum algorithm, standardise on one number length etc. so that the spec can be implemented in half a dozen lines of code, but that's herding cats :-(
Posted Sep 14, 2024 14:09 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
It's amazing the number of people who it never occurs to to try and get it right. I've just been asked to implement a check on lorry driver hours, and my FIRST reaction was to ask the requester to send me a copy of the appropriate regulations.
I think this will be the third regulation I've implemented a check for - the previous one was "a driver cannot work for more than 13 calendar days without a 45hr break". The guy who implemented the previous version of the check thought all he needed to look at was the previous, current and next calendar week. How can you check a 13-day rule if at the start of the week you can only see back 8 days! And he just couldn't see what was wrong with it.
Cheers,
Posted Sep 14, 2024 16:27 UTC (Sat)
by farnz (subscriber, #17727)
[Link] (3 responses)
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.
Posted Oct 2, 2024 8:22 UTC (Wed)
by taladar (subscriber, #68407)
[Link] (2 responses)
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.
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).
Posted Oct 2, 2024 10:34 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
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,
Badly coded websites
Wol
Badly coded websites
Badly coded websites
Badly coded websites
Badly coded websites
Wol