Captcha won't verify

The captcha module uses session variables, which IIRC require cookies enabled - any chance that the problem users have their security / privacy settings ratcheted down when visiting with IE?

Oh, I should mention that I've had people complain about this problem on my sites, although I've not been able to reproduce it.

You can ask the users to add your site to IE's "Trusted Sites" zone, which should eliminate any security settings related issues - if a cookie restriction is the issue,

I agree that you can't expect users to do this on a large scale, but it could help diagnose the problem, so if you can find a user who has this 'issue' and it disappears when your site is in the trusted sites zone, then we have more information.

And, I have just heard from a friend (running FireFox!) - she can't get past the captcha module on one of my sites - keeps being blocked by the captcha module even though she enters the correct answer. So, I'm going to visit her home and see if I can diagnose this problem. (They may be using an internet security suite, like Norton or whatever, so that may be a factor.)

I've seen it happen on a local test system, with IE7, when the local test site was removed from the Trusted Sites zone. The local site had Drupal caching enabled - disabling the Drupal cache seems to have fixed the problem (I don't know why, yet.)

If your site has Drupal caching enabled, try disabling the Drupal cache and see if the user can use the captcha-enabled form successfully.

I've been reading this thread with worry and puzzlement. So i tested my own site out with IE 7 and logged straight in, no issues at all.

Also my signups don't seem to have gone down.

What may be interesting is if your using text or image captcha's. I'm using the former as the latter always drives me insane. Maybe something to look at ...

I think there's something funky going on - between Drupal page caching, browser cache settings, and privacy/cookie handling settings, I'm seeing very strange behavior in this module, and yes, people (including me) are having problems passing the captcha filter.

I'm disabling this module on my sites as well, until I can dedicate the time to figure out what's going on. Too bad, as this is a much-needed module.

Desm0n:

I've been reading this thread with worry and puzzlement. So i tested my own site out with IE 7 and logged straight in, no issues at all.

Also my signups don't seem to have gone down.

What may be interesting is if your using text or image captcha's. I'm using the former as the latter always drives me insane. Maybe something to look at ...

I'm using the text captcha, and I tried updating all sites to the latest 4.7 version ( $Id: captcha.module,v 1.29 2006/12/23 14:22:09 wundo Exp $). We are definitely seeing problems across several sites.

I've been getting complaints / inquiries from people who can't get past the text captcha test, both IE and Firefox. User registrations are down a bit, too.

Due to recent spam site contact form postings, I had enabled the captcha point on all site contact forms, and since the people who can't get past the captcha challenge can't submit a contact request, I'd be willing to bet that I've not received as many complaints/inquiries as I might otherwise have. (My sites are not so compelling that people will jump hurdles to access them.. which is why the captcha module has to perform flawlessly on my sites.)

For now, I'm disabling the module on all my sites (and I'll be hit by spambots, but that's better than the alternative). When time permits, I'll try to diagnose this locally on my test system.

One observation: Drupal page caching seems to be a factor - for example, on the site contact form page (example.com/contact) the same page content (containing a captcha form element and session variables) is served up by the drupal site, so if I hit page refresh in the browser, or clear the browser cache, I do see the same captcha question presented more than once - so that's a potential issue, and I'm not sure how to get around it.

Shouldn't the captcha form always present a different challenge to the user on every page view? Is this flaw due to Drupal page caching, or is there some way to override caching of pages from inside hook_form_alter() or some other hook?

Please understand, I think this is a great contribution, it's just that something is amiss and I want to try to help fix it. Unfortunately, I don't have any great debuggers available, so it's back to dumping variables and poking around under the hood.

One thing to check - is there more than one captcha showing on a page?
Ensure that you don't have captcha points enabled on the User Login Form Block!
If you have a page that has the captcha enabled (like a contact form or user login page), and it also contains the user login block, the session variables will be in conflict (two captchas on the same page is a big no-no due to race conditions caused by the captchas using the same session variables)

Interesting problem. I know some of have had this but have not been able to duplicate the problem which makes it hard to try and fix it. Here is something that might be effective.

Find the code:

/*
 * Default implementation of the captcha challenge & validation
 */
function captcha_captchachallenge(&$form, &$captcha) {

  $x = rand(1,10);
  $y = rand(1,10);

  $captcha = ($x + $y) . '';
  $form['captcha_response'] = array (
    '#type' => 'textfield',
    '#title' => t('Math Question: What is %problem?', array('%problem' => $x .' + '. $y)),
    '#defaultvalue' => '',
    '#description' => t('Please solve the math problem above and type in the result. e.g. for 1+1, type 2'),
    '#weight' => 0,
    '#required' => TRUE,
    '#validate' => array('_captcha_validate' => array())
  );

}

and replace it with:

/*
 * Default implementation of the captcha challenge & validation
 */
function captcha_captchachallenge(&$form, &$captcha) {

  $x = rand(1,10);
  $y = rand(1,10);

  $captcha = ($x + $y) . '';
  $form['captcha_response'] = array (
    '#type' => 'textfield',
    '#title' => t('Math Question: What is %problem?', array('%problem' => $x .' + '. $y)),
    '#default_value' => '',
    '#description' => t('Please solve the math problem above and type in the result. e.g. for 1+1, type 2'),
    '#weight' => 0,
    '#required' => TRUE,
    '#validate' => array('_captcha_validate' => array('captcha_response'))
  );

}

Here's a unified diff patch for that suggested change (I changed #defaultvalue to #default_value since that's what the forms api docs say is correct)

cvs -z9 diff -u -F^function -- captcha.module (in directory C:\devroot\cvs-drupal\contributions\modules\captcha-HEAD\)
Index: captcha.module
===================================================================
RCS file: /cvs/drupal-contrib/contributions/modules/captcha/captcha.module,v
retrieving revision 1.29
diff -u -F^function -r1.29 captcha.module
--- captcha.module	23 Dec 2006 14:22:09 -0000	1.29
+++ captcha.module	2 Jan 2007 21:02:56 -0000
@@ -154,23 +154,23 @@ function _captcha_validate($captcha_resp
 }
 
 /*
- * Default implementation of the captcha challenge & validation
- */
+* Default implementation of the captcha challenge & validation
+*/
 function captcha_captchachallenge(&$form, &$captcha) {
 
   $x = rand(1,10);
   $y = rand(1,10);
-
+  
   $captcha = ($x + $y) . '';
   $form['captcha_response'] = array (
     '#type' => 'textfield',
     '#title' => t('Math Question: What is %problem?', array('%problem' => $x .' + '. $y)),
-    '#defaultvalue' => '',
+    '#default_value' => '',
     '#description' => t('Please solve the math problem above and type in the result. e.g. for 1+1, type 2.'),
     '#weight' => 0,
     '#required' => TRUE,
-    '#validate' => array('_captcha_validate' => array())
-  );
+    '#validate' => array('_captcha_validate' => array('captcha_response'))
+);
 
 }
 

***** CVS exited normally with code 1 *****

Care to explain why you think this might help? What is the problem this patch is trying to address?

Here's a site that fails to work properly with my IE7 config:

http://amadorable.com/

Visit the 'contact' link and see if you can get past the captcha to send me a message.

If you are successful once, please try again. It fails for me just about every time, when not logged in (uid==0, anonymous). Site caching is enabled, and set to minimum of 5 minutes.

That site is using captcha.module,v 1.29 2006/12/23 14:22:09

I tried your website inactivist and i see entirely what you mean.

This isn't happening on my website, or at least it doesn't appear to be but i do have page caching completely disabled. Do you have yours enabled ? Maybe this is the route of the problem.

Yes, caching is enabled, and set to minimum 5 minutes. (I think I mentioned this before, but who knows...?)

Even if I disable the cache (which I have just done) and clear the cache, the problem seems to persist...

Very odd. Something is terribly broken

Well as you say something seriously isn't right. Unless your cache isn't clearing ?

The only difference between the two setups i see is cache on vice cache off. Mine seems to be behaving perfectly but i've never had the need to turn on the cache in honesty. I really can't think of it being anything else. Something somewhere HAS to be storing different lookup values to those its presenting on the frontend.

I've created a patch to add logging when user's captcha entry is incorrect. Perhaps this can help diagnose these sorts of problems.

This issue may be a duplicate of (part of) http://drupal.org/node/80615 (!) Definitely should check out that issue.

my code above in #10 passes the captcha_response form element into the _captcha_validate function in the line:

'#validate' => array('_captcha_validate' => array('captcha_response'))

Depending on the PHP version without the 'captcha_response' at the end the form element may not be passed to the validate function.

With a lot of sites, the FIRST time I post an answer to the math question it won't verify, then the second time it always verifies. Just posted a comment on http://www.angrydonuts.com/displaying_views_exposed_filters and I got this error.

Some people mentioned problems with textimage. My problems with captcha occur only with textimage. Half of a character and sometimes a whole character will end up outside the image which means you cannot type in the correct response. See http://drupal.org/node/77554. This problem occurs at the server when generating the image, which means it occurs in all browsers. I installed the latest textimage from HEAD and still had to adjust $imageWidth and $imageHeight.

@peterx - that is a different problem and not associated with this one. I, too, have run into that and had to make adjustments.

I get the same situation as in post #20. I have page caching enabled and think that's the issue. Check out this scenario:

Not logged-in, using http connections:

1. I validate a form in FF with the question: 4+4 = 8. Works fine.
2. I go to the same form in IE6.0, and get the same question - but it doesn't validate (probably because the question has changed - but not for the page cache).
3. After not validating, the question changes in IE6, now it validates just fine.

I haven't tried turning off page caching. But I'm not sure that's the best solution either - as some ISPs cache pages on their own.

SSL should get around ISP and browser caching. I'm not sure if the securepages module servers Drupal cached pages. In theory, it shouldn't. But I haven't tested that.

Thanks for the info.

Changing title back to "Captcha won't verify"

Sorry about changing the title....

Just ran into this CSV module for 4.7 that was just put out on Jan 14th. Might help: http://drupal.org/project/cacheexclude.

-s

Is there a way to tell Drupal to NEVER cache a page? Can this be done programmatically from within the captcha module?

Appending a query parameter to the URL will defeat browser caching. Drupal core is doing this now for post-login refresh - it appends ?time=unix_time_string to the URL to force the browser not to cache the page. (I forget which issue this was, but this was rolled into 4.7.3 to fix complaints about users logging in, then seeing a cached page after the login.

Thanks for the info about cacheexclude.

I'd prefer not to have to install & configure YAM (Yet Another Module) to fix something that is broken in captcha module. If the technique used in cacheexclude is relatively straightforward, I'll see if I can integrate the technique into captcha module, and I'll upload a patch.

Here's the meat of the cacehexclude module:

/**
* Implementation of hook_exit().
*/
function cacheexclude_exit($destination = NULL) {
global $base_root;

if ($destination == NULL) {
$pages = explode("\n", variable_get('cacheexclude_list', ''));
$this_page = request_uri();
foreach ($pages as $page) {
$page = trim($page);
if ( strstr($this_page, $page) !== false ) {
cache_clear_all($base_root . $this_page);
return;
}
}
}
}
So, at the end of every page request, this code is run, and the cache is cleared for all matching pages.. so, for captcha, we could (optionally) do this for any page on which the captcha module has inserted a captcha. (And, unlike the cacheexclude module, I suggest this only be done if site caching is enabled...)

Comments? Anyone think this is a bad idea?

I'm having the same problem with CACHE Disabled... Appears to be happening to only users of IE7

Hm.. sounds like we need to split this into two issues - "Won't verify when site caching enabled" and "Won't verify IE7 users".

I noticed I am having the same problem. The captcha is being cached. I agree with the first approach of tackling this like #28 suggests. Clear that cache.

@tracerrx - does your captha change each time you reload the page? Is your host caching pages at all?

Since I'm seeing this on two sites without cache (ever) enabled, and in Firefox as well as IE, I've started a new issue to that effect here - http://drupal.org/node/144685

For us, we think we have the problem figured out. Our issue was limited to IE7 when the page was framed. IE7 is very strict about cookies, and when the page was framed by a "foreign" parent page no cookie was created. So the session associated with the creation of the captcha was not associated with the submission of the form (which created yet another session -- albeit without any captcha value). Of course the captcha validation fails. Basically, while framed in IE7 (by a page not coming from your server), you are in a truly sessionless environment.

Since our captcha is for commenting only (with no login), we're going to rewrite the captcha module to include an encrypted version of the captcha code as a hidden form field. Upon submission we'll decrypt and compare the value from the hidden form field to the value typed in by the user. This should enable commenting.

We still have the issue of about a billion sessions being spawned when users come to our site via a foreign frameset and stick around to surf pages.

If others are interested, we'll post the code here.

This issue should be resolved in 5.x-3.x.

Closing this issue:
* Maintenance and support for the CAPTCHA module for drupal 4.7 are already a long time inexistent. Considering that the Drupal 4.7 branch is now officially unmaintained due to the recent Drupal 6.0 release, it is very unlikely this will change.
* We are also working on a CAPTCHA design that does not require cookies and will avoid the related problems. Currently in HEAD (for drupal 6) by http://drupal.org/cvs?commit=101505