This isn't an original concept; I read it somewhere, can't remember where now. But I don't know that this is implemented in Drupal anywhere and am considering a small module to do it. I'm looking for feedback along the lines of:
- Any reason why this wouldn't work?
- Is there already something that does this?
- Can you think of any roadblocks?
Basically, this is yet another technique to discourage the many bots that try to create accounts at Drupal sites, or hack contact forms to send spam email to members. The technique would probably work for other kinds of forms, but those are the two biggies.
The technique stems from the observation that most bots fetch and submit forms really fast. While a human will typically take seconds, or 10s of seconds, to complete a form, a bot will generally do it in under a second. So basically, the solution is to not accept a form that's submitted "too fast."
This won't completely deter bots, of course, but it will slow them down.
Here's the basic idea of the module:
- Present an admin interface that lets the admin specify a list of form ids, and a minimum process time.
- Use hook_form_alter() to attach a '#value' item to each form of that type, where the value is the time the form was served.
- In the form validation, throw a form error if the form is submitted too soon after the serve.
The error won't wipe out the form, so a human could wait a few seconds and resubmit. Like I say, this won't completely block bots, but it would slow them down.
Another variation would be to keep track of the IP addresses of the submitters, and only allow one form submission per N seconds from a given IP. This would be more work, but would reduce the possibility of parallel submissions from the same bot.
Thoughts, anyone?
Comments
There are lots of modules
There are lots of modules that can help deter such usage, http:BL is one example. A module like IP address module could be useful if implementing a custom solution.
Good pointers, but...
Those are good pointers, nevets, but I don't think they fit my limited use case. I run a site for a local organization with a much more limited target audience than most. No accounts allowed to the general public. No input (comments, etc.) from other than registered users. Different, of course, from many sites that want to attract as much participation as possible, but I know we're not the only site in this niche.
Given those parameters, the spam activity is pretty much limited to:
Recaptcha on those forms eliminates a large percent of the spammer requests for both, but a few still get through. Mother May I has been 100% effective at blocking the first, but there's still the occasional spam "contact" submission. It isn't a huge problem, but irritating when it happens. I'm just trying to reduce it even more.
Your references don't seem to address this type of abuse, and even if they did seem more heavy-weight than warranted for this particular use case.
I don't know, I may pursue this idea. Not right now, though.
There are a couple of troll
There are a couple of troll modules that might help though I do not think is possible/practical to eliminate all spam.