• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Validation, Servlet or not?

 
Zein Nunna
Ranch Hand
Posts: 245
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,

I've just built my website, most of the validation i.e. if a field has is complete or not, is done inside a servlet. My question is this the correct/best way to do it? Or should the validation be done on the actual JSP via JavaScript and then once all the data is valid the page can be passed to the Servlet? [I know JSF/Struts can aid in validation but I choose not to use them for other reasons]

I have heard that JavaScript can be turned off, hence I wouldnt want to comprimise my security.

Thanks in advance for your thoughts, regards
Zein
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64178
83
IntelliJ IDE Java jQuery Mac Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can validate the data on the page in JavaScript to give the user quick feedback, but never ever ever rely on client-side validation.

Always validate your data on the server even if it's already been validated on the client. Not only can JavaScript be turned off, but requests can easily be spoofed with bogus data.
 
Zein Nunna
Ranch Hand
Posts: 245
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Bear

My main concern is that by doing server-side validation it will slow down the system down alot relativley speaking.

However given your reasons I suppose its neccessary even if it does slow down the response.

Thanks once again for your advice.
Regards
Zein
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64178
83
IntelliJ IDE Java jQuery Mac Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Zein Nunna:

My main concern is that by doing server-side validation it will slow down the system down alot relativley speaking.


Firstly, I don't see how even intensive validation can be anything but a blip in all the processing and network overhead that goes on.

Secondly, even if there were performance implications, sacrificing data integrity for a few exta milliseconds doesn't seem like a wise trade-off to me.
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd go even further than Bear and say you should perform validation on EVERY layer boundary.

So the client performs validation to catch what it can, then the servlet engine performs validation for data integrity and security.
When that servlet calls an EJB that EJB performs its own validation (after all, it could be called from elsewhere by a process that isn't controlled closely).
If that EJB calls a mainframe, the mainframe again performs validation.

And on the way back you should put in sanity checks as well to see if the data you get back is within expected limits, to prevent things like man in the middle attacks (or merely working with data from a corrupted database).
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64178
83
IntelliJ IDE Java jQuery Mac Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeroen T Wenting:
I'd go even further than Bear and say you should perform validation on EVERY layer boundary.


Totally agree.

My model and business code also performs data validation. Since the business/model code is written to be completely independent of any UI, it has no idea where the data is coming from. A Swing UI? The command line? Other?

Remember when your mother used to say "Wash that! You don't know where it's been!"?

Same principle applies.
[ August 21, 2006: Message edited by: Bear Bibeault ]
 
Scott Selikoff
author
Saloon Keeper
Posts: 3890
16
Eclipse IDE Flex Google Web Toolkit
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Speaking on performance, do you have benchmarks to support your worry that too much validation will slow down the server? Granted, complex business validation aside (such as those that would require a trip to a database), most validation like string parsing and number formatting can be handled quickly. If you're really concerned in a particular implementation, I'd run benchmarks with and without validation and then weigh the results.

As for me, I agree with validation should be done at every boundary but there are areas you can optimize (or rather different boundary lines you can draw) such as restricting access to ejb/web certain components based on where the request is coming from and then adding full validation on that outer layer.

For personal preferences, I add all database validation that can be accomplished with foreign key constraints and uniqueness and have the top layers of the application server do the rest including business validation since it is best in a position to make all the calls neccessary to validate business logic. I rarely do JavaScript validation unless its a performance gain (for example, you don't need to drain the server with senseless calls if javascript can tell the user they didn't fill in a number). Think of javascript validation as a performance enhancement, not to replace any real validation.
 
Steve McClintic
Greenhorn
Posts: 14
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Scott Selikoff:

I rarely do JavaScript validation unless its a performance gain (for example, you don't need to drain the server with senseless calls if javascript can tell the user they didn't fill in a number). Think of javascript validation as a performance enhancement, not to replace any real validation.


If the client has JavaScript enabled, then catching an error in the client with JavaScript is better than waiting for the server to catch it...even when the server would catch it anyway.

/Steve McClintic

[ August 23, 2006: Message edited by: Steve McClintic ]
[ August 23, 2006: Message edited by: Steve McClintic ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic