[UPHPU] RE: Javascript form validation [was Re: Posting a form]
Jeffrey Moss
jeff at opendbms.com
Thu Feb 24 14:31:55 MST 2005
Javascript "validation" (at least in the broad sense you're using it) has
some pretty awesome uses too, like I did a site that didn't have a security
certificate and I set it up to encrypt the password in md5 before submitting
the form. You have to make the md5 algorithm in javascript, you can get
that on the web. I think Hotmail and Yahoo mail both use this for their
non-ssl login page.
As for the form action being parsed on the fly, sometimes it is necessary
when you have two different forms on one page and you need a little of both.
This is a problem with the original form specs not being flexible enough for
some things, like if you have an iframe with a form in it, and you need to
include some data from outside the iframe, you might either have to insert
variables into the form or re-parse the action string. They're mostly hacks,
but I'd hardly call that validation.
One of example of this off the top of my head that I find very useful is
this: www.realtor.com, when you type in some parameters and click "advanced
options", it captures everything you've already selected and uses that on
the advanced options page, which is extremely convenient for me.
If you don't have javascript enabled then maps.google.com won't function at
all, and that is one of the best user interfaces I've seen. Same with Google
suggest.
Give a more specific example of how javascript validation prevents access to
the site by spiders? I dont want spiders going into order pages... unless I
had a site with some sort of navigation gizmo that did funky things with
javascript and forms and stuff, spiders can still navigate the site. Can
spiders access popup screens? I bet some are designed to bypass the
onClick="javascript:popup" subroutines. If I were making a spider I wouldn't
want it to trace into form actions.
I think javascript is at a mature level right now, and the best websites out
there are going to make extensive use of it.
-Jeff
----- Original Message -----
From: "Mac Newbold" <mac at macnewbold.com>
To: "Benjamin Schmuhl" <schmuhl at minglematch.com>; "UPHPU List"
<uphpu at uphpu.org>
Sent: Thursday, February 24, 2005 2:06 PM
Subject: [UPHPU] RE: Javascript form validation [was Re: Posting a form]
> Today at 12:48pm, Benjamin Schmuhl said:
>
>> This is a problem we want to overcome. I don't want to use a submit
>> button because I want to use javascript to validate the form before it
>> can be submitted. Is there any way to have enter validate the form? Do
>> I have to put listener events on each form element?
>
> I don't want my reply to be taken in the wrong way by anyone, so know
> right now that I mean this in the nicest and most helpful way.
>
> Javascript form validation is a pet peeve of mine. Because it is client
> side, it is not guaranteed in any way to be run. It is insecure. It can be
> faked, skipped, avoided, disabled, and any number of other undesirable
> things. Search engines don't run any of it either, though that doesn't
> have much to do with form validation in particular. People can even make a
> form like yours, but without the javascript, and submit _that_ instead of
> your form.
>
> Before I go further, let me say that client side validation (and other
> client-side functionality) has its place. In many cases, it can make the
> user experience better by providing faster response than submitting the
> form to the server, and it can do things that the programmer thinks are
> helpful, like updating other fields as values are selected or entered.
>
> However, because it can be [easily] bypassed, it is of absolutely no use
> for guaranteeing that the form submission meets certain criteria. The only
> place that can be done is on the server side, where the programmer has
> complete control over the data and the validation performed on it.
>
> I've seen horrific things in this regard. One in particular that makes me
> cringe is when I saw a site that used Javascript to calculate the amount a
> credit card would be charged, and the server side blindly accepted
> whatever the javascript told it, and billed the card that amount, and
> considered the bill paid in full. Another javascript abuse I saw used a
> form that did not have a valid action, so the form didn't have anywhere to
> submit to, and by means of javascript, validated things and proceeded to
> (incorrectly) fashion a GET string, then set the page's location to that
> string. I've seen others that do a pretty good job in the javascript of
> validating things, but when the page was submitted, did absolutely no
> validation on the server side. To make matters worse, I saw all three
> things on the same site, one that I did not write, but which I was hired
> to debug, repair, and complete. I've seen most of those things in plenty
> of other places too, at least the client side mistakes.
>
> Another thing to keep in mind is that if your site will not work with
> javascript disabled, you are closing out a significant portion of your
> potential users. And I'm not just talking about the wierdos (like
> bigdog_ut ;) ) who use Lynx for normal browsing. In the worst case, you're
> locking Google, Yahoo, MSN, and the other search engines out of your site.
> (If that doesn't matter to you, it probably should.)
>
> Every site should be functional and usable (at least) without javascript.
> If it has more bells and whistles with javascript, fine. But it should
> still work without it.
>
> A statistic I found recently stated that a significant (10%-20%) number of
> users have javascript completely or partially disabled in their web
> browsers. And no, that isn't one of the 93.61% of statistics that get made
> up on the spot.
>
> Sorry for the rant/diatribe/flame as it may be percieved. I'm just going
> about trying to help people not to make the same mistake that so many
> people have already made (and in many cases, are still making).
>
> So _please_ don't depend on javascript for validation. Use it if you like,
> but back it up with all the same (or better) validation on the server
> side.
>
> Thanks,
> Mac
>
> /me thinks he's going to turn this into an article on the uphpu.org web
> site, too...
>
> --
> Mac Newbold MNE - Mac Newbold Enterprises, LLC
> mac at macnewbold.com http://www.macnewbold.com/
>
> _______________________________________________
>
> UPHPU mailing list
> UPHPU at uphpu.org
> http://uphpu.org/mailman/listinfo/uphpu
> IRC: #uphpu on irc.freenode.net
More information about the UPHPU
mailing list