The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I agree with the accessibility points which I was of course aware of before posting the article. The aim was to provide an example of how one might structure and develop such a CAPTCHA system, not necessarily to provide an all singing, all dancing solution. In many areas the example was simplified to make it possible for as many people to try it out as possible without running into problems caused by complex dependencies. I choose to use built in fonts for exactly this reason.

I'll be posting a more complex example on my web site in due course which makes use of TrueType fonts, a better background noise system and provides an answer to the accessibility issues for those that are interested.

I've updated the code for this class to reflect some of the comments I received. It now supports TrueType fonts with random character rotation, optional character shadows, better background noise and has support for background images.

I'm still looking into the accessibility options but will post here when I have a solution.

Big big ommission here unless I'm missing something. I implemented this almost as is, but the condition used to check if the correct code was entered doesn't check if a code was ever created!

The whole point of image verification is to stop bots. However, bots were getting around my script using this image verification simply by entering no value in the verification field. Since they don't pick up sessions anyway, the empty "code" in $_POST is equal to the empty "code" in $_SESSION, so their input was accepted!

I added a check that the variable existed in $_SESSION and had a value.

Thanks for pointing the problem out. I've contacted SitePoint with a fix and asked them if they'll update the article. In the meantime I suggest that anyone that wants to use this code replace the line which checks the code with the following:

Thanks for pointing the problem out. I've contacted SitePoint with a fix and asked them if they'll update the article. In the meantime I suggest that anyone that wants to use this code replace the line which checks the code with the following:

You also need to unset the code from the session after a successful verification. If you don't, a human can type in one verification image value and then set their bot loose to submit an unlimited number of forms an unlimited number of times on that website using the same security image script. Once the code is known, the check will always pass, as a bot won't request a new security image before posting again. I've experienced it personally.