<br><br><div><span class="gmail_quote">On 2/10/06, <b class="gmail_sendername">Matt Warden</b> <<a href="mailto:mwarden@gmail.com">mwarden@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>Shawn Milo wrote:<br>> For my ASP pages, I find that using JavaScript as much as possible to<br>> validate the form before it is submitted saves me a *lot* of work. If
<br>> something is entered incorrectly and the problem is found after the page is<br>> submitted, I then have to put all of the values from that page into<br>> variables and insert server-side code into each HTML object to conditionally
<br>> set that content as the default value for the object.<br>><br>> With JavaScript for validation, you simply refuse to allow the page to<br>> submit when something is wrong. The user loses nothing if there is a problem
<br>> repopulating a field, and there is no delay as the page reloads or<br>> refreshes. Plus, you don't need to have extra server-side code which<br>> re-creates the entire input page *or* moves on to the next step, depending
<br>> upon the validity of the data.<br><br>No, actually you are completely wrong.<br><br>Send me the URL to your application, and I will break it in about 1 minute.<br><br>All I would need to do is turn off JavaScript. This development
<br>methodology makes the assumption that any submitted form has already<br>been validated. This is a poor assumption. There are (a) malicious users<br>that would realize this and turn off JavaScript, and (b) white hat users
<br>who don't have JavaScript turned on in the first place (probably more<br>than you think).<br><br>JavaScript validation is a *user aid* to help the user correct problems<br>without a round trip to the server. Its purpose is for the user, not
<br>your application. You protect your application by validating *all*<br>values on the server side.<br><br>- --<br>Matt Warden<br>Miami University<br>Oxford, OH, USA<br><a href="http://mattwarden.com">http://mattwarden.com
</a><br><br><br>This email proudly and graciously contributes to entropy.<br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.1 (GNU/Linux)<br>Comment: Using GnuPG with Thunderbird - <a href="http://enigmail.mozdev.org">
http://enigmail.mozdev.org</a><br><br>iD8DBQFD7MCKrI3LObhzHRMRArgvAKCad6vnwjPm2WnpiCJnggNtAEK3vACdGfon<br>cROmsucZDGhWty1lU1R601c=<br>=CmYG<br>-----END PGP SIGNATURE-----<br>_______________________________________________
<br>Javascript mailing list<br><a href="mailto:Javascript@LaTech.edu">Javascript@LaTech.edu</a></blockquote><div><br><br>Extremely valid points. However, my applications are not accessible from the Internet, and the users are very small in number and need the application to do their jobs day-to-day. Also, the most likely outcome of invalid data is an error message when they submit the page because a database INSERT or UPDATE command fails due to invalid data.
<br><br>Obviously, the right thing for me to do is use the methods you espouse, not only from a security standpoint but also from a simple compatibility standpoint; the closer the web app looks to boring HTML, the better it is for most browsers.
<br><br>I guess I'm spoiled in my sandbox.<br><br>Shawn<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="https://lists.LaTech.edu/mailman/listinfo/javascript">
https://lists.LaTech.edu/mailman/listinfo/javascript</a><br></blockquote></div><br>