On Fri, April 21, 2006 4:56 pm, Nicolas Verhaeghe wrote: > I have functions which dynamically generate client-side javascript > validation functions according to the name of the field, its type > (text, password, email, drop down, radio button, textarea, and what > not). > > Same thing server-side. Allow me to expand on why I think this is (generally) a wrong-headed approach. Consider a simple, common example: The phone number. Now, if you're doing this the Right Way and restricting only to the characters known to be valid, then you want only: [0-9] To be nice to users, maybe you allow '-' and space as well. Of course, if it's taking international phone numbers, you want to let them type that leading + sign, but not if it's US-only. Now, if it's a businees-oriented phone number, you want to allow something like: 1-800-CALL-ATT because, by god, they paid big money to get the digits they want and the right to promote/market that 800 number with alpha-characters in it. Yet, to be as restrictive as possible for non-business use with home telephone numbers, you wouldn't want to let that slip by, so you can avoid more pranksters. If you look at it carefully, most of your data in most of your applications *IS* that complicated. Phone numbers? See above. Postal Codes? US or World? Zip +4 or not? Should you not cross-check with country code and a specific regex, for those countries where you KNOW what it should be, and you expect many users? Email address? Man, you could spend a year trying to get this one right, and still have it wrong. So, all-in-all, the "rule" for how to sanitize data, IN MY OPINION, is too application-specific and too domain-specific to be generalized and maintain the level of security most programmers and clients would desire, given the cost/benifit ratios involved for using a pre-packaged sanitizer, or a clear in-line regex of what is kosher for THIS application and THIS domain. To drive this home: If the rule is complicated enough to want a generalized function to handle it, it's probably complicated enough that you do NOT want to over-generalize by using a package function, but want to use the RIGHT regex for that application. This is just my philosophical position, and I'm NOT the expert. ---------------------- You can always take it to the nth level and end up not verifying everything but you can prevent most common mistakes. As far as email address, make sure there is something that looks like "a@xxx". Same with Zip codes. You can CASS certify it all you want but you'll never be sure that the address is correct until you send snail mail. The idea of such client- and server-side verification is to prevent mistakes that the user could make unwillingly, for instance mixing fields: typing something else than the email address in that field, without realizing it. You can force someone to enter data into a field that absolutely needs to be filled. So far, I have rarely seen people entering fake data into shopping carts or online forms. Why? Because most people don't have time to waste screwing around filling online form with junk. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
