Server-side Vs. Client-side Validation Revisited
CF Muse Reader Asks:
You suggest both client and server side should be used for validation. Just to check - I should code so that js picks up the errors first using event code or onsubmit then let server side pick up the errors on submit using cfinput validate/required etc. Or do I recode all the stuff to be event driven such as onchange etc.
This question refers to the previous post on form validation. From the way the question is phrased I believe the reader is probably proficient at JavaScript. There are some amazing things you can do with JavaScript, and I'm in favor of creating intuitive interfaces that help your user cope with the complexity of your application. Obviously JavaScript is or can be a big part of that solution. If your concern is to provide a better user experience then JavaScript is helpful and necessary. If your concern is to validate your data for accuracy and security then you must use server side code to check your form inputs.
Read More12 Comments
-
In every presentation I've ever done about client-side validation, I've always made the point that server-side validation is the most important aspect.
Client-side validation basically just improves the UI for the user. I'm a strong advocate of client-side validation, but I've also seen people spend to much time trying to bullet proof their client-side validation while ignoring server-side validation.
Client-side validation should be designed to catch user mistakes and notify them of the mistakes quickly. Server-side validation ensures that the values receive constrain to your business logic rules and that they don't break your code. -
I agree with you there..
It's like the story of the fireman, who has pants and suspenders, sure the suspenders are nice, but if they fall and you have no belt, how will you hold your pants up?
So use client validation, it's great as a first step for validation..But have the server side just in case, especially if you use it within queries or any other highly sensitive to hackers.
<cfqueryparam
<cfparam
all ways to specify datatype's for incoming variables.
Even if your not using it in a query, what if the data isn't the datatype you expect and they had javascript off?
cfif isdefined(form.my_variable)
sure the above prevents if the variable does not exist
but what if you need a numeric value and you get a string garbage as well.
Good post, mark. -
While this is somewhat off topic and a whole different paradigm, it is worth noting that using flex, we will be able to rely more on client side validation, because first, there will be no way to turn it off unless they just dont use the form at all, and secondly, you are able to easily created very complex validation routines, similar to what we can do with cf on the server side, in actionscript on the client before it is sent to the server for proccessing. You may still need to do some basic checking on the server side, but it wont be as much of a problem as it is with html and javascript. -
Craig, While flex does make it more difficult to hack, it still generates client side values that are ported to the server. Using something like "service capture" by Kevin Langdon (http://www.kevinlangdon.com/servicecapture) you can upack web service and AMA calls pretty handilly. Doing it all on the client side in flex only amounts to security by obscurity. It's better than pure JS, but it still has a fatal flaw. -
Webservice calls, yes, but I dont think this will be a problem with the coldfusion adapter. The way I understand it, it will be all binary data going back and forth. I would be very surprised to see someone be able to hack that. Now, if you are just using a flex swf to do an http post to a page, yes, the same issues reside, but using the cfadapter (mystic) I dont think you are going to have that problem. I would be interested in finding this out for sure though.
-
It's okay, Mark. We're all human, we make mistakes...:)
-
The Coldfusion adapter uses AMA - flash remoting. This is an open binary format. The tool I mentioned by kevin langdon unpacks it for you and gives you the send params and the received data in a visible and readible format :)
Remeber too that a cfc that is enabled for remoting (meaning access="remote") is capable of receiving web service calls as well as AMA calls.... so armed with the URL you would be able to generate the WSDL, create a stub/proxy class and utilize it as a web service.
That sounds like a lot of work, but even novice developers armed with user friendly development tools that abstract the process of unpacking the XML could probably make short work of it.
Yes it IS more work than simple HTML forms, and hence "more secure" because it's "more difficult" in the same way that a $500 pound home safe is "more secure" than a $100 dollar home safe. Both, however, are still Home safes - and they don't do much good if the thief can simply abscond with them and pick them at leisure.
My point is that no matter what you choose to do on the client (and all these ideas are marvelous) you still need server-side validation. -
The Server side validation in CF is just rubbish. There is no apparent way to turn it off (please englighten me if i'm wrong).
In fact, its been like this forever, and I'm sure people requested one of the many CF 'owner' companies to fix this and at the very least allow this stupid auto validation to be turned off. But why would the listen - some issues are best kept for the next 'owner of the platform' to deal with. It has caused me a great deal of headache as I"ve had to work around this many times.
(don't tell me to rename my fields as this is not always possible. A field titled "request" and one "request_date" are logical fields to be present in a database/form/app.) -
Harel,
I agree about the server side validation - and I don't know anyone who uses it. I would never used "canned" validation for anything important anyway. I made that very point above.
As for "turning it off" so you can use your pet naming convention... why would you NOT be able to rename a form field? My only conclusion is that you are using "cfupdate" or "cfinsert" to get your data into your database. that is also a bad idea. Write SQL insert statements instead. Cfupdate is too restrictive and gives you very little feedback on what's going on under the covers. And you can't leverage SQL either - as in a combined insert/update statement.
That's my take - so I agree with you half way ... is that good enough for us to remain friends? :) -
Man,
If you assume I'd use a useless tag like cfinsert/cfupdate then we won't BE able to be friends in the first place ;o)
The application i'm working on is most likely the largest CF application in the history of this (silly) platform. I can't disclose the details though I can say it is used by many government authorities in the UK and by that definition - that makes it huge in the sense of the biz logic and strictness it uses. It's bolted on an old (over 10 years) oracle db whose columns cannot be changed.
The app is built on a framework I created which kinda resembles hibernate but on steroids. Think 'automatic gui generation with total db persistency'. The amount of forms this app generates is HUGE. Renaming db fields is out of the question. The framework is solid, and runs many apps within it as modules. Infact, I wish I could release it somehow (I can't obviously).
We worked around that problem though the very existence of this kind of silly issue adds additional nails to the coffin of CF.
I can't help but wonder - if the next CF owner is Microsoft - would it be renamed ColdFusion MS?
(i was kidding of course - we can remain friends - just don't mention cfinsert/update ever again ;o)
Sites to Watch
Aggregators
RSS
