This is horrible advice. Let's take it a bit at a time.
Wow, what misconceptions!
Let's debunk this load of myths right here and now.
First, Javascript is sent by your page, not by someone elses. If there is subversion to happen, it would have to be at your codes hands... not someone elses.
Um..no. The kind of subversion that is being discussed is someone figuring out what your page would send back and then submitting a page that sends back a version with unexpected edits which are designed to break your back-end code.
Please tell me how the code I send to the requestor is somehow intercepted and my javascript is ripped out of the stream and replaced by some malicious user? It that were the case, then all your efforts would be for not anyway since a malicious user as you call them could change any content as well on the fly.
A malicious user can indeed mess up their own experience all that they want, and nothing I do can protect them from themselves. I'm fine with that.
I'm not fine with the malicious user sending me data which will cause stuff to break on my server, thereby possibly affecting other people.
Next myth, it will break on certain browsers. You can write javascript that works on 99.99% of all browsers and ( now this may sound incredible ) check to see what version of both Javascript and even what version of client the requestor is running. We actually do that at work in our application and send the user a friendly note and link on how to upgrade their browser to accomodate easier browsing. When they have Javascript disabled because of policy, we send them information on what our script is doing to make their page navigation easier at our site and how to disable it again after they visit our page.
First of all more than 0.01% of browsers turn JavaScript off.
Secondly people turn JavaScript off because it is a security problem!
Thirdly I've yet to see a site that attempts the approach you describe and doesn't wind up not knowing what to do with random third party browsers (firefox, opera, etc). Most just figure out that it isn't IE and tell people to upgrade to a browser that is so insecure that even the US government says not to use it.
All of which goes to say that any site which tries to tell me to "upgrade" immediately goes into my list of morons to avoid.
16 possible round trips to a Website to validate one part of a form should be sending you a big message. And that is just for two parts of a form. What happens when the requirements grow in the future??
Now here's some rumor control for you.
Normally when someone fills out a form, they fill it out correctly the first time. If you have good error messages (eg you highlight all fields that need correction), they'll probably fill it out right the second time. The number of round trips is far less than you are describing.
Good griefl, you will have to check each param that now involves that new form item in Perl... It will be much less work to simply reuse what you have already done and onchange="validate_date( this );" in your HTML, but apparently, everyone is marching to a misconception that EVERYTHING MUST BE DONE WITH PERL. PERL IS NOT THE SOLUTION TO ALL PROBLEMS... Hey, I would be in heaven if it were, and would love it if it were embedded in everyone's client... but it is not ( yet ;-).
Writing the validation in Perl is exactly as much work as writing it in JavaScript. If you actually care about security, then you'll have to write it in Perl eventually. Why do the work twice?
(Or you could take the CGI::FormBuilder approach and automate the validation routines entirely. I'm not sure how well that works in practice, but it is an interesting idea...)
The last myth, you will have to do twice as much work testing and maintaining: I completely disagree! I think you will have a solution that you can use over and over and over. You will separate form validation from the rest of the page. It is much easier to test this way also.
You will have the same amount of effort and you place that code in a separate file and link it in through your sheet!
If you set up the Perl backend correctly, you get all of the benefits that you're claiming for JavaScript, without the worries about people potentially breaking your validation by simply ignoring it.
I also think you are off base in your misconception that you are only mainting perl with this effort. If you read between all the curly braces... there is yet another language you are maintining... called HTML and perhaps CSS too.
Where did this accusation come from? Nobody intelligent thinks that Perl is the only language being maintained. You are maintaining a website. The question is how to best do that. Trusting the client in a hostile environment is generally not the way to do it.
And yes, my employer wants me to do this. Believe it or not, I used to think like you do, but was shown the light. It was either that or the door, but I liked the light better, it put food on my family's plate.
Then I feel pity for you, to work for an employer that is that stupid.
My guess is that employers who are competent enough to let people like me make design decisions like this are likely to do better, and may even pay more. This is in addition to being better places to work, and the comfort of knowing that I have the security of having actually built the site correctly.
At work, I am THE STRONGEST ADVOCATE OF PERL. I LOVE PERL. But really if you are doing Web work and only know Perl/HTML that ain't enough!
Oh I agree that you need to know more than just Perl and HTML (and SQL and...). I certainly know more. In fact I've been known to do some pretty sophisticated JavaScript when the right occasion comes up.
But I also know enough to do these things appropriately. Which usually means making the JavaScript entirely optional, and not trusting that the client actually ran it.
Nuff said...glad that is off my chest.
Well if ranting relieves your blood pressure, I just gave you some more material to rant about. | [reply] |
Now that's what I am talking about... this is a real discussion now.. :0) Really... this is getting a little too personal with calling employers stupid and such. I understand the limitations and security problems with Javascript and you are afraid someone asking for help on the board here is unaware of the risks. I commend you for promoting the general wisdom and I agree with you if the user doesn't know what to embed in his scripts he could compromise his security and your advice to newbies is more politically correct than mine. I was sparking debate only to point out that I see way way too many folks in here often overlooking the most obvious. I remember one very long post about a guy having issues with DBI being slow... and everyone trying to have him try to use selectrow_arrayref instead of selectrow_hashref, I pointed out that it sounded like he didn't have an index on his table. And, it turned out he didn't. I wasn't saying I was smarter... this site has some brilliant minds on it. I just was saying... hey, try this. ;-) Have a great day tilly and thanks for discussion.
JamesNC
<br.
| [reply] |
Please tell me how the code I send to the requestor is somehow intercepted and my javascript is ripped out of the stream and replaced by some malicious user?
Well, they can edit the page themselves and load it from their own harddrive. Or spoof a POST/GET browser request manually, using telnet. It doesn't matter. The point is that he will still need to do this validation server-side, and there's no way to avoid that.
I still agree that using Javascript for these things is great. Makes the whole thing snappier and more interactive. But you still have to have at least barebones safety checks server-side.
| [reply] |
