It’s an ever preset problem that plagues every website owner, freaking form spam. Some moron builds a bot or tries to hack your contact form in an effort to try and grab quick links or send out emails. Maybe, just maybe, I found an answer.

Stopping Form Spam With AJAX and Captcha

As my Article Site Manager Application™ became more popular more of the sites that ran it started experiencing the same problem. Hundreds of bogus articles were being submitted, thousands of fake contact forms being sent and even more fake requests for links, all of them nothing more than form spam. At first I approached the problem like most other developers, by adding a captcha image verification system, but that only slowed the nonsense down. I had to fight fire with fire!

About the same time I renewed my interest in AJAX applications. After some thinking I came to the conclusion that I could possibly stop 99% of this spam if I combined an AJAX submitted contact form (or any form) along side the standard Captcha image verification.

After some testing and a few failures I came up with a two part form system. Simply put anyone submitting any type form would have to do the following:

1. Fill out the submission form as any other form
2. Submit the form
3. Review the formatted submission, enter the Captcha image verification number and then submit the information

Now this seems like a simple process but behind the scenes a lot is going on, most of it trying to stop spam. First off I have removed the normal submit buttons from the forms. Instead I use the onclick event of a normal button input. That eliminates the possibility of a non Javascript enabled 'bot' of even attempting to submit the form. The onclick event calls a Javascript function that does your normal 'front end' type data checking. If that fails the client gets the oh so normal error alerts.

If the inputted data passes the first check validation the Javascript function then calls a server-side application via an AJAX call. The server-side application retests the data and if it finds an error the front end Javascript missed it returns an error code to the Javascript. Of course these error codes need to be handled based on what code comes back from the server-side application.

For instance, the article submission form in the Article Site Manager calls a server-side application that not only checks for the proper data, it tests the article for a minimum word count and checks the article’s title and content for bad words that are stored in an array. Each error returns it own code to the Javascript so you can tell the customer what error was found. Error messages are coded into the page in divs with their display property set to none. When the Javascript is passed an error we simple switch the divs display to block to show the error. Its just a little classier that the normal Javascript alerts.

If the server-side application does not find an error in the data it returns the data to the Javascript in a formatted manner. For instance, the Article Submission Form (which BTW formats the article in standards based HTML) returns the article and it’s code exactly as it would be live on the site it is being submitted to. We 'turn off' the form by setting its display property to none and 'turn on' a div that will contain the formatted article. We 'inject' the properly formatted code into the div by simply setting the innerHTML property of that div to the code that came back from the server-side script. The client can then edit the information if there is an error or they can do a final submission of the information.

The final submission (formatted article, link, whatever) also contains a Captcha image verification image and text field. Again, before they submit the final time the Javascript checks to make sure something is entered into the the text box. If there is something there the Javascript sends another request to the server-side application. This time the server side application first checks the image verification code against the code that’s stored in their session. If the code is incorrect the server-side application sends back another error code and the error is displayed to the client. IF the code is good the information is submitted and a success message is given to the client.

The beauty of all this is that by using AJAX the page is never reloaded, it appears to be done in real time for the client. Secondly you are able to test and retest the data over and over until you are happy with it. Lastly we shut down access to any bot that can’t run Javascript. So what about those people that shut off Javascript? Personally I say 'Oh Well'. The numbers are so small (usually under .1% of your traffic) that I don’t see how it's a big deal.

Ill update this article after we have run this for a few months and let you know but I will say that in the first week of running this new code I have yet to receive one spam submission!