This is a re-post of an idea I posted on topliners.eloqua.com - but since I just saw some spam posts in the Revo forum, I thought I'd post it here as well and get your feedback and ideas. Maybe some version of this technique could be incorporated into Discuss at the post form level, so that even if a bot manages to create an account, it will have difficulty actually posting.
However, I'm not sure this technique would have stopped the bot that was posting in the Revo forum, since it apparently somehow got past the "keep things human" test in the account creation form. This method is basically the same, with a bit of JS added to avoid bothering the user with the question if they have JS turned on - that may not matter on an account creation form, but on any sort of lead gen form you want to lower the barriers to entry as much as possible.
I've been struggling with form spam recently, and found a solution that I like and thought would be worth posting about. I tried the "honeypot" technique described in this post:
http://topliners.eloqua.com/community/do_it/blog/2013/04/19/experiencing-automated-form-spam-submissions-try-the-honeypot-method-to-counter-it, but I found that some of the bots attacking my forms were sophisticated enough to detect that the honeypot field is hidden, even if I used CSS or JavaScript to hide the field. So I tried a modified version of this technique which seems to be working well.
Step 1: create a "honeypot" field
- Create a new text field in your form (not a hidden field, we'll hide it with JS later).
- The field label should be a question with an answer that would be obvious to any human, such as "what color is the sky?" If you're not confident that it's obvious enough, you can put something in the field instructions that says "just say blue." This is necessary so that the form will work with JavaScript disabled.
- Set up your form processing steps to run conditionally only if the value of this field is "blue" or whatever the correct answer is. With FormIt, this could be done by using "contains" and "maxlength" validators.
Step 2: hide the field using JavaScript
- Don't use CSS to hide the field, because you want it to be visible if JavaScript is disabled so that the submitter can correctly answer the question.
- Use JavaScript to set the "display" property of the field (or preferably, one of its parent elements) to "none." See sample jQuery code below.
Step 3: populate the hidden field using a JavaScript event
- The idea here is to use JavaScript to fill in the correct answer to the hidden field when the user takes an action that any human would have to take in order to fill out the form.
- I settled on using the "focus" event on all form elements because even if the user is using their browser to auto-fill the fields, they will still have to place focus on some form element in order to submit the form.
- If you use some other event, make sure that it's an event that any human user must trigger in order to submit the form, but not one that is automatically triggered when the page loads (such as window load) because some bots may be smart enough to execute it.
Example Code (uses jQuery)
<script type="text/javascript">
$(document).ready(function(){
$('#formElement7').hide();
$('input').focus(function(){
$('input[name="sky"]').val('blue');
});
});
</script>
Where formElement7 is the id of the honeypot field's parent div, sky is the name of the honeypot field, and blue is... well, the color of the sky. Obviously replace these values as needed for your form.
So far this is working well for me - I'll post updates if I find that there are problems or if I want to recommend modifications to the technique.