form validation, client-side AND server-side?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

 Is it considered current best practice to implement client-side form
validation unless Javascript is disabled on user's browser, then
server-side validation comes into play? Thanks.

Re: form validation, client-side AND server-side? wrote:
Quoted text here. Click to load it

Sort of off topic . ask your php questions here not JavaScript

What your asking is a matter of personal opinion.
I personally dislike JavaScript I go out of my way to avoid it. This
comes from a long time of using websites before JavaScript and Flash
became mainstream.

No matter what checking you do in JavaScript it won't help your php
script, but if done correctly it can help the user. Your facing a
usability issue here and thats purely subjective.

No matter what you do on the client side ( as I have been discovering
lately ) you have to treat everything that gets sent to your script as
suspect and check your data.

I'm sure someone here can suggest newsgroup that can be better suited
for more detailed answer.

regards trookat

Re: form validation, client-side AND server-side?

trookat wrote:
Quoted text here. Click to load it
Well trookats answer actually raises the point of what 'considered
current best practice' means.

That is a highly subjective question, and his answer clearly reveals his
honestly expressed bias. "Avoid java shit like the plague".

Having been forced to embrace the pile of wombats turds through no
realistic alternative, I can say from my perspective that it is entirely
down to what is driving your coding: using javascript nets you a very
much faster response to validation issues at the time of validation, but
you may need to download a lot of data to actually be able to do a
meaningful validation.

I have a situaion like that: a hierachical tree of indexes to objects.
So teh user ca searh and find things by traversing a menu system that is
user modifiable.

However, that brings a very real hazard, if the user modifies it from a
tree with branches and leaves, to a loop, leading to infinite recursion
when traversing it.. I can easily check if they have tried to do this,
with a server side warning, but it would be a lot nicer if they were not
able to actually see the situation at all in the browser to set it up.
But that is a step beyond teh complexity of javascript I am prepared to
go right now.

A lot also depends on whether you are writing a site over which you have
very little control of what browser is used. Basic forms and server side
script is more ubiquitous than client side javascript. And places less
stress on possibly mobile hardware at the far end. OTOH if it is, as is
inmy case, an application used by obly a few people all of whom are
customers, and all of whom have a house standard browser, it is no
problem to ensure a predictable javascript environment.

Re: form validation, client-side AND server-side?

Quoted text here. Click to load it

It is considered current best practice to ALWAYS validate on the
server side, regardless of whether you think Javascript is disabled
or not.  Remember, anyone can save your form, edit it, and submit
it with a fake REFERER.  Or they can turn off Javascript after you
check that it's working.  Anything else you try to do to make sure
they are using your form on your site is a waste of time, from a
security point of view.  They'll get around it.  CURL makes it
fairly easy.

If you want to implement client-side form validation IN ADDITION
TO (and duplicating) server-side validation, fine.  It may give
more immediate feedback, and it may be more user-friendly.  Just
make sure you don't set up a maze the user has to go to a lot of
effort to find his way through.

Example:  you (as a user) are trying to schedule a reservation on
a particular date.  This is presented in 3 drop-down boxes for
month, day, and year.  There is Javascript checking for a valid
date at each change (not just on submission).  The default reservation
date is tomorrow.  The reservation date must be from tomorrow to 1
year from today, inclusive.

Current date:    January 28, 2009
You see:    January 29, 2009
You want:    February 14, 2009

BUT:  You can't change January to February because February 29,
2009 is not a valid date (2009 is not a leap year).  You can't
change 29 to 14 because January 14, 2009 is in the past.  You can't
change 2009 to 2010 because January 29, 2010 is too far in the
future to take a reservation.  You can make this work by changing
the month to March, the day to the 14th, and the month to February.

Now try setting up a reservation for January 1, 2010.  The only way
I see to make that work is to pull up the page above, wait until
after midnight (hoping your session doesn't time out), change 2009
to 2010 (Since it's now January 29, 2009, it's OK to set the date
to January 29, 2010), then change the day to 1.  How many users
would figure that out?  Of those that did, how many would bother
staying up past midnight to try it?

It's OK to put up a warning about an invalid date, but refusing the
change before the user is done with the changes is annoying and
potentially drives off customers.

Re: form validation, client-side AND server-side?

Thanks much Truecat and Gordon, I was just wondering why people still
use javascript form validation if it has so many holes. I will
probably end up using only server-side validation for what I am
working on as now I see there is no point of using BOTH at the SAME

Re: form validation, client-side AND server-side?

On Dec 9, 7:52=A0am, wrote:
Quoted text here. Click to load it

Client side validation has its uses, but think of it as a usability
aid and not as a security feature.  It can save time by helping users
spot where they've failed to fill out required fields, but the wrong
kind of data in a field, etc, without having to submit the form to the

For client side validation I'd recommend you try jQuery along with the
jquery.validate plugin, it provides a pretty comprehensive library of
common validation tasks and doesn't require you to invest excessive
amounts of effort in your client side validation.

Re: form validation, client-side AND server-side?

On Dec 8, 10:40=A0pm, wrote:
Quoted text here. Click to load it

ALWAYS validate on the server.  You can add client side validation
too, but you should treat client side validation as a user aid, meant
to help guide them through the process of filling out your form.  If
you treat client side validation as a security measure, then you
simply don't have any security.  All the user has to do is turn off
the scripting engine in their browser and they can submit anything
they want.  They can't circumvent server side validation so easily.

By all means, have both client and server side validation, but focus
your attention on the server side, as this is where it matters.

Site Timeline