File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSP and the fly likes client side validation vs Server Side Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSP
Bookmark "client side validation vs Server Side" Watch "client side validation vs Server Side" New topic
Author

client side validation vs Server Side

vara prasad
Ranch Hand

Joined: Dec 21, 2004
Posts: 47
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?
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
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).


42
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

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.


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Rigel Kentaurus
Greenhorn

Joined: Feb 09, 2005
Posts: 11
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.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60997
    
  65

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.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

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

Joined: Oct 12, 2000
Posts: 5093
If you don't return an error message it's kinda pointless to do validation is it?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60997
    
  65

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

Joined: Dec 11, 2004
Posts: 13410

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

Joined: Oct 12, 2000
Posts: 5093
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60997
    
  65

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

Joined: Dec 11, 2004
Posts: 13410

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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: client side validation vs Server Side