I was wondering how many of the failed CAPTCHA attempts were likely caused by human error as opposed to blocked spammers, and after analyzing the logs concluded that (at least on my site) all the responses that are not empty are made by a human not being able to figure one of the characters.

I think that this information is quite useful to a site admin, so I made a change in the log functionality that enables separate record and summary of the failures (empty and wrong).

Sorry that the patch is not against HEAD.

Comments

Status: Needs review » Needs work

The last submitted patch, log_fail.patch, failed testing.

soxofaan’s picture

Version: 6.x-2.3 » 6.x-2.x-dev
Status: Needs work » Needs review

Good idea,

And maybe, we can take this a bit further:
- provide a hook "hook_captcha_log($form_id, $solution, $response, ...)" that would be called on CAPTCHA issues: wrong response, empty response, CAPTCHA session reuse attack, ...
- move the handling of these log items to a separate module, to make the core CAPTCHA module a bit lighter (both in UI and in code) and still allow for more advanced processing of the issues in the external/optional module (e.g. daily summary, weekly summary, email warnings, ...)

What do you think?

PS: if you create patches, it is indeed recommended to do it against 6.x-2.x-dev (CVS branch DRUPAL-6--2), there seem to be a problem with the automated test system. Anyway, even though you created the patch against 6.x-2.3, it could still be applicable to CVS branch DRUPAL-6--2. Let's try...

miopa’s picture

log_fail.patch queued for re-testing.

miopa’s picture

Unfortunately I can't contribute serious code right now.

The one feature that I need the most is a summary similar to /admin/reports/visitors, where I can list and ban hosts from where most of the failed CAPTCHA originates. I'll try to implement this next week and post a patch.

Status: Needs review » Needs work

The last submitted patch, log_fail.patch, failed testing.

soxofaan’s picture

miopa’s picture

Status: Needs work » Needs review

Here is an updated version, including new 'Log' tab, and removing the counter in the variable.

I think the absolute counter is not that needed, and the performance pressure could be great because of all the spam bots trying to submit unaware of the CAPTCHA (my captcha_wrong_response_counter is i:14125;).

With this patch only stats about the period covered in the Watchdog table can be seen, but for me this is even better because it reflects current situation.

I don't have time to take this further, so if anybody is willing and able, please do :)

miopa’s picture

StatusFileSize
new6.51 KB

I'm sure I attached the patch in the previous message.

Status: Needs review » Needs work

The last submitted patch, 998326-log_fail.patch, failed testing.

miopa’s picture

I don't get this 'failed testing' thing.

Undefined variable: wrongCount

It isn't defined because there is no need for it to be.

miopa’s picture

Status: Needs work » Needs review
StatusFileSize
new6.49 KB

I hope I won't annoy the test bot :)

Status: Needs review » Needs work

The last submitted patch, 998326-log_fail.patch, failed testing.

soxofaan’s picture

if (variable_get('captcha_log_wrong_responses', FALSE)) {
  $wrongCount = db_result(db_query("select count(*) as cnt from {watchdog} where type = 'CAPTCHA'   AND severity = " . WATCHDOG_INFO));
}
$form['captcha_log_failures']['captcha_log_wrong_responses'] = array(
     '#type' => 'checkbox',
     '#title' => t('Log wrong responses'),
    '#description' => t('Report information about wrong responses to the !log.', array('!log' => l(t('log'), 'admin/reports/dblog'))),
    '#description' => t('Probably valid user. Currently: !wrongCount',  array('!wrongCount' => $wrongCount)),
     '#default_value' => variable_get('captcha_log_wrong_responses', FALSE),
);

The problem is that when the variable "captcha_log_wrong_responses" is false, you use the $wrongCount variable (in the description) without it being defined/assigned a value.

Also some minor remarks about code style:
- In Drupal code, we use two spaces for indentation
- we put the opening brace "{" on the same line as the "for", "function", "if"
- we don't use camel case/dromedaris case ($wrongCount), but underscores: $wrong_count
more info here: http://drupal.org/coding-standards

thanks for your work

miopa’s picture

Status: Needs work » Needs review
StatusFileSize
new6.36 KB

The problem is that when the variable "captcha_log_wrong_responses" is false, you use the $wrongCount variable (in the description) without it being defined/assigned a value.

I forget that PHP fires notices for that shit. This should pass.

wundo’s picture

Issue summary: View changes
Status: Needs review » Closed (outdated)