A crucial element of building and maintaining a database is data integrity – making sure your information is accurate and in the correct format, unchanged by technical glitches. You can personally verify information if you are entering it manually, but when users are filling out forms on your Web site, and that information goes directly into your database, you need another approach.
There are two places to check data validity: on the client and on the server. Checking data on the client involves adding scripts to your Web pages that examine what the users enter before they submit forms to your server. A script checks that the data in the form meets the criteria you have established. If there is a violation, the script can pop up an alert message and request a correction.
To check data on the server, the user must submit the form and let the code on your server verify the data. If there is a violation, your server can return the form again with a notation of the error that needs correction.
In general, server-side checks can be more thorough, as you can check other resources on your server to validate the information. For example, you might have a database of valid discount codes, or you might check that an email address is not already in your system. However, client-side checks provide more immediate feedback to the user, and can save iterations of submitting a form and then correcting any errors. A balanced combination may prove the best choice.
A simple check on the client side could be a matter of confirming whether the user entered any value at all.
More Sophistication
Your checks can be more sophisticated. For example, you can make sure an area code was entered as three digits. And you can see if an email address contains invalid characters like a space, or if it’s missing the @ character.
In some cases you may need to examine more than one form element at the same time, such as only validating an area code if the user has selected the US or Canada. You can add a name property to the form tag. Your JavaScript function would be passed the name of the form, let’s call it “myform,” and could reference a specific form element value like “myform.test.value.”
Once your form has passed all of its client-side checks, it gets sent to your server where more sophisticated checks can be performed. If you have a database of area codes, you can validate that the user entered a legitimate one. Or, you can ensure that a user has not already signed up for your program or for your service.
If the data you receive from a form is placed directly into a database, then it is even more important that you check the information on the server before storing it. Depending on how your server performs its database access, it is possible that users may include data-base commands in their submission that could directly affect your database.
Another example is a search form, where your server performs a search through your database. If the user can search for an email address based on a name in your maillist, and the server executes “select email from maillist where name=”<name>'”, where <name> comes directly from a form submission, then the user could get your entire maillist.
If they submit the name text “‘; select * from maillist where name matches “*”, then both selects would get executed. The first would produce no results, but the second would match every entry in your maillist. If your code looped through and displayed the results of the select, assuming that only one or two matches would occur, then this example would end up displaying your entire maillist.
In both cases the user would have to guess the name of your table, but it seems there are people out there with nothing better to do.
EDWARD ARENBERG, vice president and CTO of EPage, created one of the first fully dynamic Web sites. He manages and develops for EP.com, Epage.com and AdConnect.com.