Joey Adams Dot Net

Most developers I talk to, including myself, cannot stand form or any user input processing. You have to check, re-check, check again and then check again before sending the data to the model which checks the integrity again, and if something is abnormal the whole process starts over again.

I will say this a lot but I really mean this guys, preparation and planning really helps. Before coding anything, sit down with a pencil and paper or your favorite UML editor .

Lets assume you already have a database set up for the required user input. I would go into schema design, but that is a different topic. So you want to take user input, process it and store it in the corresponding database table.

If you have your database set up correctly, this is actually not that daunting of a task. Often, developers attempt to check the submitted data to make sure it conforms to what THEY want (size, format, integers, html etc). This is the wrong approach, we should be organizing and formatting our data to conform to what the DATABASE (or model) wants.

A huge issue in application security is data integrity. You can manipulate user input all you want, but when you pass the data to the database, if something happens during storage that alters the record (injections, incorrect format, anomalies) then you now have arbitrary data in your application flow that can cause all sorts of problems down the road. We need to be in control of our data and know exactly what it looks like wherever it is in our application.

What you should do first is make a list of the variables that your form will handle, that will be inserted into the database (give yourself room if on paper). Underneath (or wherever) each variable, put the data-type and flags set for it in the database. {varchar(50) primary key}.

Beside each variable you will write your rules. Here you will write rules to insure the data complies with the structural format you expect in your application. I find it easy to record these as questions (is it an email address? is it a phone number? is it xml?).

After those rules, we need to add a few more. Write down your database rule requirements at the end of your previous list. (eg. is it unique?{primary key} is it less than 50 chars long {varchar[50]} is it an integer {int}). We write these rules last, as these will be the last ones processed before being sent to the database.

People may wonder why we have a global set of rules. Shouldn’t the model handle database rule logic, controllers handle application logic, etc? This is one way to do it, but I prefer having one, big, complete rule set for our variables.

The reason is not only integrity but usability. You NEED client side verification while doing form processing. If you have a multi-part form, then you need to be doing verification at each step. People get extremely frustrated with filling out forms, and even more so when they have to do it multiple times. So why should we ‘OK’ form data on the client side only to have it fail database logic verification? Users are going to become untrustworthy and feel as there is something wrong, and question the safety of their data.

If we have uniform rules that are used to check the data, then if it passes client side verification, then it should pass both application and database logic verification. In zend framework, we have decorators and highly extensible builders that make this task easy. If you are not using ZF, take some of the following steps.

Use your brain and come up with a modular solution for classing your data verifications. This should be extensible in whatever way you seem fit($username = new form_db_users_username($_POST['uname']); ) ($uname = \Form\Db\Users\username($_POST['uname']);)

As I have indicated in previous posts, I support proper OOP usage, and believe highly that it can solve many poor programming habits. Find a good OOP approach for your form creation, or use commonly used programmatic designs if using a framework.

A good example of this, is having an extensible Form/Database interaction class that is meant to be extended by either a table or property class. For instance, we have a ‘username’ class extending our database class which is an extension of our abstract Forms class. The ‘Forms’ class is meant to be extended by a class determining the form’s function.

Even better we can use polymorphism, late binding or any sort of overloading to make a template for our extended classes to follow. For example, must-have methods such as (isValid() and xmlRules()). Where isValid() would contain logic to step through each rule and validate the given variable. xmlRules() could return our ruleset in xml format which could be loaded and parsed by a javascript function on the client side. Even more, you can add annotations to your class file that show what rules the data should pass along with how it correlates with the database (data-type etc).

Hell, why not think out of the box. Store your rules in xml or in the object in another easily parse-able format and have your “isValid” function parse the stored rules and use them for validation.

If you build the functionality correctly into your application, this will give you a centralized location for data verification. If you use the above method, than any problems with validating a rule can easily be debugged and modified using a single rule set which is then used throughout your program.

Using these practices will keep you from random logic errors stemming from arbitrary data that may have been mangled during your application flow or storage.

Stay tuned for more tips…