I downloaded the module and adapted it to work with Comments forms. In the process, I was trying to come up with a way of making it work with any form, and make sure it was not dependant on any specific field.

As a result I ended up using 2 fields on the module, one which will hold the token returned by the ajax call, and a new one which will hold a random value, generated on the PHP side of things, which is what will be used for the ajax call.

Also, I changed the JS so that instead of IDs it ises the "name" of the field. this is so that we don't rely on field IDs that can change if formas are reloaded using ajax (on each ajax call the IDs get an "--#" appended to then) or if the same form is shown more than once on one page.

I'm attaching the module as I am using it right now.

Hope it helps.

Members fund testing for the Drupal project. Drupal Association Learn more


yuriy.babenko’s picture

Assigned: Unassigned » yuriy.babenko

Hi jm.federico,

Using a PHP-generated token instead of a unique field is actually exactly what I've been meaning to do in order to add support across all forms. Interesting note about the id vs. name attributes - will look into that. BTW, you didn't attach anything.

jm.federico’s picture

4.76 KB

What, where did the module go! Crap, re-uploading (i swear drupal ate the attachment)

jm.federico’s picture

Status: Active » Needs review
13.38 KB

I forked your project to github and made a lot of changes


I'm attaching a patch that includes all the changes, which are (most of them)

  • Work with any form
  • Make it generate seed using PHP
    • Can be every form: *
    • Exact matching (user_register_form)
    • Pattern matching (comment_node_*)
  • Change use of #IDs to name attribute on form fields
  • Remove vertical tabs on config page (IMO no need for it)
  • Send 403 when spam detected (don't know if it is really useful)
  • Add second field for validation, that should arrive empty
  • Implement hook_update_N for new setup

I think those are all the changes.


jm.federico’s picture

Last patch had som typos, updating.

jm.federico’s picture

Just for u to know, since I installed this module my SPAM practically stopped. It is so far the most effective method I've found.
I've tried everything including all sort of different and annoying captchas, analysis services (like mollom, which din't do much) and this is the only one that worked!

So a true and honest thank you!

yuriy.babenko’s picture

Thanks for all this! I'll review it ASAP in the next couple days and get it into the main project.

RE: removing vertical tabs - I put those in place as I have a few other things I want to add to the module, and those items will require their own configuration options, which I'm planning on putting into other vertical tabs.

RE: 403's - have to think about this one and do some research. Might be some issues with legitimate bots such as search spiders.

jm.federico’s picture


RE: Vertical Tabs: Ah, didn't know. :D

RE: 403: I've been thinking about it, but in theory no legitimate bot should ever get there as they shouldn't fill the form. 403 is only shown on form submission which fail validation. No legitimate bot would ever fill the form (would they?). I've done some search and haven't found much. All I was thinking was a way to not only avoid spam submissions but to also stop them from coming back, cause they still use a lot of resources when submit a form.

The extra field, which is not really necessary to stop spam, is because I'm doing a quick comparison to see how effective it is against the AJAX version. The reason being an ajax call pero protected form might be a lot for some sites.

I'm thinking that if using JS is what needs done, in theory, it should be possible to just send the value that needs to go on the field as part of the Drupal.settings and just put it there and store the original in $['form_state']['whatever'], no ajax request.
I'm amazed how effective this system is, but I'm a bit worried that on really busy sites it could be too hungry!


yuriy.babenko’s picture

jm.federico, sorry for the very delayed response.

First off, huge thank you for the work you've done. I just integrated it into Badbot (with only minor changes), and things look & work great. The only notable change I made to your patch is setting #tree = TRUE for the badbot_wrapper element within hook_form_alter() - the reason being to eliminate any potential naming conflicts between the honeypot field (last_name) and a legitimate field of the same name which may be present in a given form.

Everything's committed and pushed. Will be releasing 7.x-1.1 momentarily.

yuriy.babenko’s picture

Status: Needs review » Closed (fixed)