Show Captcha After X Unsuccessful Attempts

I was about to open a similar feature request, but I did a search first and ran across this issue. It would be nice to have an option similar to what Mollom does, where the capture only appears when triggered by certain bad behaviors. Wufoo recently rolled out similar functionality across their forms.

hi
i have same issue
how you solved
recaptcha also not working from second attempt on wards

please share with me

I think this is a rather specialized use case and I think this would fit better in a small separate module than in the core CAPTCHA module.

I don't have the time nor resource to do this myself, but if someone else wants to do this, I'm willing to provide a helping/guiding hand. What should happen in short:

• hook into the user_login form with hook_form_alter on form_id 'user_login' and 'user_login_block'
• count the number of tries, I think you can user $form_state for your counter
• when above threshold, add a CAPTCHA element:
  

  $form['captcha'] = array(
    '#type' => 'captcha',
  )

I have the same problem. Subscribing...

I used the details soxofaan posted above to write a simple single function proof-of-concept module:

function smart_captcha_form_alter(&$form, $form_state, $form_id) {
  if ($form_id == 'user_register' || $form_id == 'user_login_block') {
    $step = isset($form_state['values']) ? (int)$form_state['storage']['step'] : 0;
    $form_state['storage']['step'] = $step + 1;
    if ($step > 1) {
      $form['captcha'] = array(
        '#type' => 'captcha',
        '#captcha_type' => 'recaptcha/reCAPTCHA',
      );
    }
  }
}

I'd like to expand the module to include an interface for adding forms, along with configurable settings for each form. Possible bad behavior triggers could include:

• missing token: if a user submits the form but fails to submit the hidden form token
• same IP: number of times a user from the same IP address can submit a particular form before triggering the captcha
• flood: x requests in y time causes the CAPTCHA to display (using flood_register_event)

Any other trigger or feature ideas?

subscribing....

I have the same need for the project that we are currently working on - we need to show captcha on login form after x login errors.

Based on #4 and #6 I have created captcha_after basic module with a couple of changes in proposed logic:

• I didn't use $form_state['storage']. I tried it and it simply didn't worked. Maybe the reason is that $form_state['storage'] should be used for multistep forms. For now module is storing counter data in session.
• Instead of adding captcha element after defined threshold, module will remove captcha element while counter is smaller then defined threshold. I think this approach is better and will allow tighter integration of captcha_after and captcha module. This will allow a user to define captcha for forms like he is used to and then he can define threshold only for forms that he wants.

Current module is tested on our dev site and it is working ok for our use case. Note that this is very basic version and it has next limitations:

• Currently it is working only for register, login and login_block forms.
• You can't choose for which form you want to turn on captcha_after.
• You can only define threshold globally for all forms.

Before doing some more coding and trying to implement some other triggers or some other feature I would like that others check proposed solution.

Thanks for sharing module with us.
I have installed this module but after that there is no captcha in login block and every where.

Subscribing for now. Will post feedback when get time to test this. This is very important feature for mitigating brute force attacks and automated bot activity.

@mnp thx for testing. I don't know exactly what is a problem you have, if you can share some more info about potential bug that would be nice so I can reproduce it and fix it. Bugs are very possible because I didnt have time to test module properly.
For now captcha_after is only changing user_register, user_login and user_login_block form and is not working with others captcha enabled forms. On that 3 forms catcha will be shown when user reach captcha_after_threshold limit (default is 3) - that means if you have captcha enabled login form and if user enters bad login data 3 times in the next reload captcha will be added to login form.

@crea yes I agree very important feature, and I was supprised first when find out that it was missing. And this is also important usability feature - because we can remove captcha field for real users.
Actually I already decided to continue to develop this module. First thing that I will add is better integration with captcha - so user can decide for which captcha enabled forms he wants to add captcha_after and define threshold per form. After that I am open to feature requests.

I recommend splitting it to 2 parts:
1) "Detector". this is where different "suspicious activity" criteria are implemented as plugins and thresholds are configured. "X failed login attempts" would be just one plugin.
2) "Action" part, where different actions are possible as plug-ins. Captcha would be one of such plugins.

Having such separated architecture will allow much more flexible configurations. Admin may want to have both different criteria for detecting bot activity (mass messaging, too fast fetching of pages etc) and different actions for reacting on such activity (logging, blacklisting user, whitelisting user after successful captcha etc).
So having such flexible solution will help in different areas: prevention of bruteforce attacks, detecting of mass mailing, mass private messaging, mass form submission, detecting DDOS botnet members (both with whitelist and blacklist).

I think that would make sense to implement on top of Rules module, cause what I describe is actually Event-Condition-Action system that Rules implements.

The captcha_after module works OK for me.
Thanks a lot pivica!!!!!

@lorcon i am glad it works for you :)

Tomorrow I will be visiting Vienna drupalcamp, after that (next week) I am planning to do little more coding and upload new version.

@crea using Rules modules, sure if it will do the job. Many nice ideas you have but all this will require lots of planing and time to implement. Maybe better idea is to first finish some basic version of this module and put it on drupal.org, after that we can create new branch with rules support.

One other trigger that could be useful is a "honeypot" field. The idea would be to add a field on the form, but hide it using CSS. If the field comes back with a value, it's likely that the submission is spam and should trigger the CAPTCHA display.

@Matt in #15:

If the field comes back with a value, it's likely that the submission is spam ...

If a honeypot field comes back with a value it is certain* that it comes from a spam bot, so why giving it a second chance? Just block the submission, no mercy (being a CAPTCHA).

* The assumption is here that all humans use a CSS capable browser (or at least one that supports hiding with CSS). An important exception are screen readers for blind people, as far as I know. A quick google query indicated however that it is still possible to hide stuff for screen readers.

FYI and reference: #743056: Document how to add a CAPTCHA programmatically

after validate user_register form:
if captcha field valid and any other field not valid then captcha will be not rendering.

after validate contact_mail_page form:
if captcha field valid and any other field not valid then captcha will be rendering.

wtf?

at mrded in #18: this is off-topic for this thread and should be discussed in a separate one. Anyway: I can not reproduce this: on contact_mail_page I get the same behavior as with user_register. Please open new issue if you want to discuss this further.

ok. I create this Issue

I imported what pivica posted in comment #8 above into git, made some updates, and posted them to a public git repository on Assembla:

http://www.assembla.com/code/captcha-after/git/nodes?rev=master

The updates I've made, so far are:

1. added the ability to specify a flooding threshold (ie, the number of times a form can be submitted in an hour)
2. moved administration page to separate file
3. changed so that any form enabled in the CAPTCHA module will now be run through CAPTCHA After

I'm also attaching a zipped version of the latest updates I've made. I'll probably continue to post updates to Assembla. Please feel free to test and report back any issues that come up.

One issue I've noticed is that form fields containing validation errors are not being highlighted once CAPTCHA begins getting displayed. I think this is due to the $form_state['rebuild'] = TRUE; line, but I haven't yet figured out the best way to fix that.

@pivica Any interest in posting the module as a project on d.o? If so, I'd be interested in being a co-maintainer, if that would be of any help.

I have finaly find some time to create a drupal project - http://drupal.org/project/captcha_after.

Except changes in #21 next things are done:
- form rebuilding is not used any more - it was ugly solution and there were also a problem that Matt noticed with "form fields containing validation errors are not being highlighted once CAPTCHA begins getting displayed".
- you can now select for which captcha forms you want captcha_after to work.
- lots of code and text cleanup.

Before releasing stable release I would like that more people review code and test dev version of module.

@Matt V. if you are still interested in being a co-maintainer just drop me a message and I will be glad to add you as co-maintainer.

It seems safe to mark this issue fixed, now that CAPTCHA After has an official release.