The only difference is that if someone wanted to write a custom script to attack the blog, they would have to make less page requests. I think this is a small enough problem that the benefits outweigh it.

I think a future version should work both ways, with a toggle in the options panel.

However, how about using a hidden (i.e. user-specifiable) secret string + some post-specific number + the randomly generated 4-digit verification code, compute the md5 hash of this and stick it into the hidden form field.

In the comment verification function, we could simply recompute the hash since we know the secret string and the post-specific number without accessing the database, using the verification number supplied by the user.

This way, a SPAM-bot would have to do at least one GET request for every post they want to comment on (granted, once they’ve done that, they could send unlimited SPAM comments to that one post, but usually, SPAM-bots only send one comment per post), but we could still get around the database access.

I’ll hack up some code later today and send it your way!

I can see your point about the database, but my choices weren’t just arbitrary and I can explain the reasoning behind storing the information in a database.

Although I don’t make mention of it, JSSpamBlock actually stops spam in two ways. The first way is the most obvious: it makes sure the client is executing JavaScript, or failing that, that a human is on the other end to type in the code.

The second way is less obvious, but the commenter is forced to make one request to the comment form every comment posted. This is not a problem for a human poster, since the comment always has to be entered through the form, but spam bots tend to skip that step and post right to the wp-comments.php file. Over half of the bots (in my test) would be blocked just by verifying that the hash was sent by the server and has not been used. By forcing the code to be checked with server-side records, the plugin ensures that the comment corresponds to one request of the comment form. Otherwise, it would be trivial to write a bot that gets around this by sending “simpleAntiSpamHiddenField=1234&simpleAntiSpamInputField_ID=1234″ on each post request. It would still be trivial to write a bot to defeat JSSpamBlock, but it would require some text parsing and, more importantly, one GET request per comment POST. On the average spam bot, the first way would require changing a few lines of code, while the second would require a small but significant addition to fetch and parse the forms. Indeed the point behind the plugin was to be different enough that no one would bother to write the trivial code required to get around it, so your plugin is actually more in line with my original vision than mine is. The problem was that once I decided to distribute it, I realized that if enough people use it, it could become worth it for a spammer to write a few lines to get around. The only way to stop this was to verify that the numbers sent to the server had been generated on the server, which required a database.

The reason I used a hash is not all that important, a numeric ID would do just as well. The only problem is that the ID would give away how many hits your blog has had since adding the plugin. For most blogs this is not an issue, but some people would rather keep that private so I use a hash instead.

I look forward to seeing how it goes. If you are going to release your code, let me know and I may send a link your way.