Günter Schenk :: Tutorials Corner
Adobe Dreamweaver Developer Toolbox

no more Captcha please -- gimme de HONEYPOT !

1. Who to keep at bay: the spambot or the visitor ?

I reckon that you, the valued reader of my tutorials, sure do know what the term Captcha stands for: it´s a contrived acronym for "Completely Automated Public Turing test to tell Computers and Humans Apart" -- yeah whatever ;-)

ADDT comes with its own Captcha implementation in order to help securing your forms against spambots, and unlike other Captcha solutions out there ADDT´s server behaviour has one particular advantage :: it generates images with random strings which are at least halfways decipherable for human beings.

So far so good, but let´s now - very briefly - touch on the disadvantages:

1. ADDT only supports Captcha when used with Dreamweavers PHP_MYSQL server model, in other words: ADDT´s ColdFusion and ASP VBscript users are left high and dry.

2. When it comes to providing image-based CAPTCHAs that are more accessible, it´s usually hard to decide on a least common denominator.

Although it´s technically somewhat difficult and requires changing some code in the "includes" libraries, you sure can configure ADDT´s Captcha implementation to have the image display more or less distorted random strings and/or display less characters -- but whatever you decide on, there´s always a remaining risk that a certain percentage of your website visitors will (for a variety of possible reasons) have difficulties when trying to decipher what´s displayed.

Although the following Captcha examples are not created with ADDT´s server behaviour, they certainly exhibit the common problem:




3. Captcha can´t be considered 100% secure, as those advanced spambots equipped with an improved character recognition software may well be able to "read" the security code anyway.


While it´s understood that at least those web applications which enable the "public" to submit data to the server (e.g. guestbooks, forums etc) *have* to be protected against spambots, there should be alternate ways to ensure the accessibility of such a protected form for human beings -- well, let´s now talk about the so-called honeypot approach and how to implement this one with ADDT.

2. the honeypotted form

Without further ado, here´s an ADDT form containing my preferred "honeypot" solution:



It´s actually a dang simple thing which will check for the term "developer", and as you can see, the form submission will fail when this very term hasn´t been entered at all respectively just partially.

However it´s obvious that the basic "accessible to all human beings" requirement is met -- and any spambot visiting this page would clearly have a *very* hard time to circumvent this protection which is only understandable to human beings, because extracting the term developer from the whole comment respectively identifying this one as to-be-submitted validation code does depend on something no spambot can come up with: common sense :-)

3. preparing your table and form

Regardless of the supported ADDT server model, the following database table preparation and form adjustments will also apply to ColdFusion and ASP VBScript users:

1. add an extra "honeypot" column to the table in question

while ADDT´s Captcha implementation works without having to alter your database table, the "honeypot" approach will depend on storing the submitted "security code" in an extra column.

Q. Why?

A: We will now be using ADDT´s standard Form Validation behaviours, and they in turn will only validate form data which is part of an Insert- or Update transaction:



In this example I defined the "honeypot" colum as varchar(32) and allowed it to contain NULL values -- it´s of course up to you to define things differently.


2. run the Form Wizard

Pretty much a standard procedure for both the Insert- and Update forms:

a) the form field properties:



b) the validation rules:




3. adjusting the form validation after the page has been generated

here comes the truly interesting part: we´re now going to make sure that ADDT´s form validation will check the "honeypot" text field against the string "developer"

Note: it´s of course also possible to define this validation setting in the previously mentioned "run the form wizard" step -- I just felt like making it a little more complicated than necessary :-)

Open the "Validate Form" server behaviour and adjust the validation rules for the "honeypot" field as displayed next:




Q 1: why do I have to decide on the "Regular Expression" validation format ?

A 1: because this is ADDT´s only validation format which allows for checking against a definite string.

Q 2: does the "Regular Expression" validation format have any possible downside ?

A 2: just one: it doesn´t check whether the entered string is uppercase, lowercase or mixed case.

4. adjusting the Update Record form

When implementing the "honeypot" solution to an Update Record form, you will just need to make a minor adjustment to the form to ensure that any previously stored content of the "honeypot" column will not be initially displayed, what would certainly defeat the purpose.

1. click on the "honeypot" field and take a look at Dreamweaver´s "Properties" panel -- it´s the default content of the "Init val" field which comes in our way:





2. clear the content of the "Init val" field and hit ENTER to have Dreamweaver automatically delete the respective recordset placeholder from the "honeypot" field as well:

5. how to check against randomly created strings

While the previously mentioned "one static value" approach may be sufficient to some users, some others might prefer an advanced "honeypot" version which creates a random string on each page load -- needless to say that this requirement would actually have to equal the functionality of ADDT´s Captcha implementation, but of course without displaying an image.

I have to admit that I´ve been racking my brain over this and tried to implement various custom PHP functions to achieve this goal, but for whatver reasons nothing worked as I expected.

By the time I got pretty frustrated and considered to surrender, I thought to myself "let´s see if ADDT´s own Captcha class does itself provide a function I could misuse for this purpose" -- and guess what: it indeed does ! :-)

Here´s the deal:

1. have ADDT´s "Insert Captcha Image" wizard add its stuff to your form as usual

2. click the Captcha´s default image placeholder and switch Dreamweaver to "Code"

3. by default you´ll see this "dynamic" image tag here:



4. in order to replace ADDT´s Captcha image with a text-only version of the very same random string, delete the whole image tag and insert the following PHP code:




Well, that´s actually all there is to do -- and thanks to ADDT´s tiny little function "getTextCaptcha" it doesn´t even take much effort ;-)

Q: will ADDT still attempt to create the Captcha image ?

A: No, because this functionality is encapsulated in the function "getImageURL" which creates the image plus returns its URL -- but as we now don´t call this function, no image will get created.