Menu
Typically when writing a web-app we want to perform validation on both client side to offer immediate feedback and on server-side to ensure data integrity and security. However, client-side browser apps are typically written in JavaScript. Server-side can be written in Java, Php, Ruby, Python and a host of other languages. When server-side is backed by something like node.js, it is really easy to re-use the same validation code on both client and server, but if server-side is based on Rails or Django (or whatever other framework you can name), what's the best way to make sure the validation code are kept on sync? It seems a bit redundant to have to re-implement the same code in multiple languages.
374
Doing input validation on both the client side and server side has a number of benefits: It helps reduce server load since invalid data is never submitted in the first place. It helps prevent malicious users from submitting invalid data.
Your apps should always perform security checks on any form-submitted data on the server-side as well as the client-side, because client-side validation is too easy to bypass, so malicious users can still easily send bad data through to your server.
Server-side validation is slower than client-side input validation. However, server-side input validation is more reliable than client-side input validation. Thus, it's safe to say that client-side data validation improves user experience while server-side input validation improves security.
Client-side validation is executed by the client and can be easily bypassed. Client-side validation is a major design problem when it appears in web applications. It places trust in the browser, an entity that should never be trusted.
If you keep the following persepective in mind, it may seem okay to duplicate certain validations.
Let's break validations into two parts. A) Business Validations e.g. "Amount in Field X should be greater than $500 if if checkbox Y is checked" B) Basic data validations e.g. datatype checks, null checks etc. (We may debate that every validation is business validation but that is purely context specific).
Category A: It is part of your business logic and should be kept only on server side.
Category B: Validations of this type are potential candidates to be placed on the client side. But keep in mind that browser side validation can be bypassed. This does not imply that you should not have validations on browser side at all but such validations should be considered merely a bonus to save network roundtrip from server. Server must re-perform these validations.
In nutshell, validations should not be considered as unit of reusable code across tiers. Their objective varies and should allow redundancy.
Hope this helps.
101
From projects I've seen there's three general strategies:
Fully duplicate client-side and server-side validation. This would require two different codebases in the case of javascript frontend and java/c#/ruby backend. You'd have to manually keep the logic of both in sync.
Do minimal client-side validation. Check for only very basic stuff. Have server side do the full validation. Have server side pass a validation-errors object of some kind back to the client and have client logic to translate that into UI messages (error messages, red borders, etc). Asp.net MVC framework is roughly an example of this model.
Use ajax to make validation calls into your server side when the user changes or leaves each control. This can allow all your validation on the server side, and will reduce the feedback wait time for the user, but can increase client to server side traffic immensely.
In my experience, option 1 is generally less of a pain point than maintaining the extra code and complexity required for option 2 and 3.
36
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
