• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

client side validation vs Server Side

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What kind of validations will be carried out on ClientSide ?

What kind of validations will be carried out on ServerSide ?

what is the best approach?
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Always validate on the server, and that means everything that needs validation!

You may optionally decide to also validate some things (maybe the most errorprone fields) on the client.

Rationelle: people can bypass clientside validation by deliberately sending unvalidated data (for example by turning off javascript or by using a non-browser client to generate the data).
 
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If it absolutely, positively needs to be validated, do it on the server.

Otherwise, it will depend on your situation.
I don't always validate on the server.

In our case, we're running an intranet type app, we validate anything that involves securty at the server.
There are a lot of non-security type components that only get validated on the client. Our app is not avalailable to the public and our users know, up front, what browsers are supported and that Javascript is required to be enabled. Since there is quite a bit of DHTML involved, it would be difficult for them to circumvent the validation. They would need to bring up a form, populate all of it and then disable JS right before submitting. In many cases the form won't submit without JS. In all cases, they would only be shooting themselves in the foot.

Client side validation is more responsive to the end user, it cuts down on network traffic, and it reduces the amount of code that needs to be maintained. So, it's nice when you can use it.

It really comes down to you knowing the nature of your app and how it will be used. When in doubt, use server side validation or both.

and..
If it absolutely, positively needs to be validated, do it on the server.
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If it needs validation... do it in the server. Then do it again in the client just to be polite.

In the server I validate mandatory input, data types, ranges, duplicate information, valid data (are they passing me something that wasn't on the catalog?) almost anything that needs validation.

Then I test and when I am really sure that the server si validating correctly I do the javascript validation for the client, that way he doesn't need a full trip to the server if soemthing goes wrong, the client side validation is a service for my client, but in the event that he had javascript disabled the application would still be secure.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Call me paranoid, but I validate everything coming into the controller, and then I validate again at the business layer (since the business layer is UI-agnostic and can't count on validation being handled by the controller).

Client-side validation, as previously pointed out, is a "user experience" enhancement, not true validation.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bear Bibeault:
Call me paranoid, but I validate everything coming into the controller, and then I validate again at the business layer (since the business layer is UI-agnostic and can't count on validation being handled by the controller).

Client-side validation, as previously pointed out, is a "user experience" enhancement, not true validation.





In each reduntant layer of validation, do you have a full mechanism for return ing the user to a filled out form or do you just do that up-front and blow up if problem data reaches checkpoint II or III?
[ February 09, 2005: Message edited by: Ben Souther ]
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you don't return an error message it's kinda pointless to do validation is it?
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

do you have a full mechanism for return ing the user to a filled out form



Yes. I have a mechanism as part of my light-weight framework that ensures that the on-page form retains its original values, displays the message(s), and can even key the error messages to particular fields when appropriate. I use this key on the client side to highlight the field(s) in error.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeroen Wenting:
If you don't return an error message it's kinda pointless to do validation is it?



I was only talking about redundant validation.
If unvalidated data is making it to your business tier, it's usually indicative of some sort of failure in the UI tier.
I could see a case for using only assertions at that point because they can be shut off after qa.

It sounds like Bear's framework can keep moving in any case.. Kudos
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ah. The way I use clientside validation is making illegal input impossible.
Usually that boils down to things like disabling input fields that aren't allowed to be changed and filtering keyboard input.

In such a scenario the server is the only one to return errors to the client.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I could see a case for using only assertions ...



I considered this (and still do), but since I never assume anything about the UI-layer when writing the business layer, I assume it's pretty dumb. Also, there are some validations that cannot be handled until the business layer or lower (those requiring database access, for example) and I didn't want to special case those that I expect never to make it past the UI layer.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeroen Wenting:
ah. The way I use clientside validation is making illegal input impossible.
Usually that boils down to things like disabling input fields that aren't allowed to be changed and filtering keyboard input.
In such a scenario the server is the only one to return errors to the client.



Yep, and I was talking about what happens when the checks, two tiers up, show that the impossible input has somehow made it up the chain. For instance, if the user has disabled JS and the validation in the controller or model has failed to catch it.
[ February 10, 2005: Message edited by: Ben Souther ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic