Are validation server controls better than javascript in any way ? Do they restrict us as we are only able to use the functionality that is provided by them. Please help me on this. I read about validation server controls from http://jai-on-asp.blogspot.com/2009/12/validation-controls-in-aspnet.html
It's best to use validation on both the client and the server:
- Validating on the client gives instant feedback without constant roundtrips to the server. This makes for a better user experience.
- Validating on the server is required to make sure you don't get bad data. After all, a malicious user could easily post data to your server without going through your client-side validation.
Now, as for how you implement that validation - if built-in "toolkit" controls perform appropriate validation for you, that's obviously going to be simpler than writing your own validation code. ASP.NET validators do both client- and server-side validation for you. From the docs for BaseValidator
:
Validation controls always validate the associated input control on the server. Validation controls also have complete client-side implementation that allows script-enabled browsers (such as Microsoft Internet Explorer version 4.0 and later) to perform validation on the client. Client-side validation enhances the validation process by checking user input before it is sent to the server. This allows errors to be detected on the client before the form is submitted, avoiding the round trip of information necessary for server-side validation.
A user can have JavaScript switched off in which case your validation routines will not be able to work. It is lawys best to do validation both at the front end as well as the server.
I have never worked on ASP but from what I am guessing ValidationServerControls are out of the box controls which give you server side validation as well as client side validation. (I may be wrong). But from what I understand, Server side validation of the components is always a requisite; as putting a validation in javascript is never sufficient. A client can always disable javascript and submit content or use sophisticated tools like curl etc. to post request to server which may contain data; that may do injection in your code/sql.
Even if you write javascript validations; you must in one way or other always write server code to validate incoming data.
Ideal approach would be to have both 1. Validate data in javascript; so that requests to server are limited in case of invalid data input. 2. Server side validation. in case javascript is disabled and data post is made to server.
In general, you always should do server-side data valdation. This ensures you protect your server from maliciously forged requests, you datastore from entering invalid data (as far as the db doesn't take care of that itself). If you like to use a tool or framework for server-side input validation, like described in the article linked by you, that is up to you.
Client-side validation, with for example javascript, is useful too, but for a different reason: it allows you to give helpful info to the user before submitting the data.
So it is not a matter of either/or, more of and/and. You are not actually doing any double work here. Client-side and server-side validation simply serve a different purpose (respectively, enhancing usability for the user and guarding logic and security of your service).
It is possible that the server and client side validations are governed by the same business logic (for example, for a zip code, you could use the same regex to check and reject input at both server side and client side). In this case you have a challenge of synchronizing both validation layers (which can be done by generating the page + javascript logic from the same business logic model as the server-side service code).
If you still feel you are doing double work, then choose to do server-side validation. (You can of course still use this to inform the client, but it will take a response to do so.) Client side validation does not offer any protection, as a client can simply manually forge a request, or, from tthe browser, disable javascript, or modify the client side javascript trhough something like a greasemonkey script.