4 ms·

It's worth mentioning that in 1999 there were already tools that helped. Perl's Taint Mode was one of them. In a nutshell, any variables containing user input c

It's worth mentioning that in 1999 there were already tools that helped. Perl's Taint Mode was one of them. In a nutshell, any variables containing user input could not be used for stuff involving OS paths, system calls or databases. The only way to use such input would be to "launder" the data, usually by using regular expressions to pull out the pieces that actually look plausible. As a side-effect, this introduced some great usability conveniences, such as numerical fields (think credit cards, age, dates…) in which the user could type all sorts of junk or poor formatting, and yet get some sane validation. Nearly 20 years later, we're still a step backwards in having what I call "Forgiving UX", and have things like rigid drop-downs to select month/year of expiration on a credit card, instead of just lifting the first 4 digits—regardless of how the user typed them—and calling it a day. https://perldoc.perl.org/perlsec.html#Taint-mode https://perldoc.perl.org/perlsec.html#Taint-mode

jandrese 8y ago
The thing that drives me crazy is when you have a form that tells you to enter the date, so you go MM/DD/YYYY and when you hit submit it comes back and tells you that it wants MM-DD-YYYY. That's something the parser could just as easily do itself and avoid making more work for the user. Ideally you would use a parser that's smart enough to figure out 95% of the cases and do the right thing and only return errors if it's completely unparseable or ambiguous. A date field should be able to accept all values like: 2018-12-13 12/13/2018 Dec 13 18 December 13, 2018 12-13-平成三十年 13.0.6.1.3 1544677200 In cases where the input is ambiguous the parser can make its best guess and toss a warning. Preferably allowing the user to inspect its guess to see if is right.
- eftychis 8y ago
  Agree, it seems this is one area that inventing your own solution is tempting, yet people fail to realize the variety of cases that need to be supported and welded together. Same thing goes for IPs etc

jandrese 8y ago

The thing that drives me crazy is when you have a form that tells you to enter the date, so you go MM/DD/YYYY and when you hit submit it comes back and tells you that it wants MM-DD-YYYY. That's something the parser could just as easily do itself and avoid making more work for the user. Ideally you would use a parser that's smart enough to figure out 95% of the cases and do the right thing and only return errors if it's completely unparseable or ambiguous. A date field should be able to accept all values like: 2018-12-13 12/13/2018 Dec 13 18 December 13, 2018 12-13-平成三十年 13.0.6.1.3 1544677200 In cases where the input is ambiguous the parser can make its best guess and toss a warning. Preferably allowing the user to inspect its guess to see if is right.

eftychis 8y ago
Agree, it seems this is one area that inventing your own solution is tempting, yet people fail to realize the variety of cases that need to be supported and welded together. Same thing goes for IPs etc