Caching with Boost, Varnish, ... causes "CAPTCHA validation error: unknown CAPTCHA session ID"

Hi, have you changed the submit value from 'Save' ? I had this problem (I had changed it to 'Submit Comment' in template.php) and got that error.

subscribe

suscribe CAPTCHA 6.x-2.0

If those problems are noticeable on a live site: please provide a link by posting it here or mailing it though my contact form at http://drupal.org/user/41478/contact

http://www.econlink.com.ar/foros/

Drupal 6.14
CAPTCHA Pack 6.x-1.0-beta3
CAPTCHA 6.x-2.0
using css captcha, math captcha works fine, so it's probably an issue with captcha pack...

I've just had someone report this problem on Windows and Mac, using Firefox - and maths captcha

Just tried myself, Safari on Mac; and comment was saved with no trouble [and now, the person reporting the issue says he's had it occur using Safari on Mac]

- seems erratic, then

I get it with recaptcha

@ frederico: thank you for the link, that really helps for investigating this problem

I tried forum and comment forms on different forum threads and noticed that the CAPTCHA session IDs in the forms (hidden elements) do not increment by one for every form (with CAPTCHA) I request. Sometimes I get lower session IDs and sometimes it just stays the same (just like the challenge stays the same).

I guess this problem is caused by your caching setup. The CAPTCHA module can handle Drupal core's caching system (it just disables caching for every page with a challenge), but if you are using additional tools and means for caching (reverse proxies and all that jazz), you are out of luck here.

So to all people suffering from this problem: please describe additional caching means you are using on your website.
Also: try to disable caching (if possible) and check if the problem still occurs.

Thanks for your help! Yes, i'm usign boost (drupal advanced caching contributed module), that may be causing this issue. Since I can't disable caching, because it'll bring down my server, and I get a LOT of spam without captcha, i'll have to disable anonymous comments.
Thanks again

I have memcache (memcachedb.inc) installed on the affected server. But, my understanding of the memcache module is that is a direct drop in replacement for Drupal's core cache...

FYI, this is the code from CAPTCHA module that disables caching for pages it puts a CAPTCHA on: (captcha.module around line 190)

  // Prevent caching of the page with CAPTCHA elements.
  // This needs to be done even if the CAPTCHA will be ommitted later:
  // other untrusted users should not get a cached page when
  // the current untrusted user can skip the current CAPTCHA.
  global $conf;
  $conf['cache'] = FALSE;

I'm not familiar with memcache, and I don't know if it follows this configuration.

Another note about using CAPTCHA with Drupal core's caching (maybe memcache too): if you enable the CAPTCHAs on forms after you enabled caching, things won't work either because the pages are already cached before CAPTCHA could prevent this. If this is the case: clear your page cache (e.g. by disabling caching and enabling it again).
This made me think it's probably a good idea to make a feature request about this: #659542: add a means to clear the page cache on the CAPTCHA admin page

Aha! - I too use Boost module

For login and contact forms, say, can at least disable caching on page by page basis, but not viable for most pages. [or, as Alex workaround below, disable caching for forms w captchas - so comment form, say, is not on same page as articles]

I have same problem.
I use Boost module.

In the form si hidden atribute:

<input type="hidden" name="captcha_sid" id="edit-captcha-sid" value="4308"  />

and this is in the cache = static HTML files. ;-)

After sending form, user get error message: "CAPTCHA validation error: unknown CAPTCHA session ID. Contact the site administrator if this problem persists."
Sending form again, can't help.

For me, this is big problem, becouse CAPTCHA and BOOST module is for Anonymous users and I can't disable one or other. ;-)

Thanx for help

Same problem here. I am using CAPTCHA on Ubercart for anonymous users. Registered users may skip with permission.
I get the error on checkout.
I do not use Boost module. As far as I know I don't have any extra caching turned on. I don't know what Ubercart does that is special.
I am using IE to test anonymous user submission.

same problem -- subscribe

I try this workarroud:

Boost Settings -> Boost cacheability settings -> Pages:

add this:

comment/reply/*

This helps.

Just received this problem too.

Many modules are installed, no boost and no other performance modules (we use the eAccelerator php optimizer directly installed on the PHP level). Normal caching is turned on - no minimum lifetime - as well as JS and CSS aggregation.

Drupal core 6.14. Captcha 6.x-2.1.
The problem only occurs on IE's 7 & 8 where the session ID is lost.

The problem only occurs when I click the "enter" button after typing in the 3 letters (without leaving the textfield). If I click the button then this problem does not occur.

Here is a link to test:
http://www.quax.at/rund_ums_baby/baby/tipps_guter_rat/7-78_figur_zur%C3%...

As a solution, I assume we can add a javascript onblur function and onkeydown "if enter then submit full form..."?

at jjchinquist in #19: there is a separate issue about this: #534168: Submit with "return"/"enter" key in IE7 leads to failing CAPTCHA, please join the discussion over there (you can skip the first comments, start at #29 or something), there is a patch for it, but it appears to make things worse, I need some feedback on this.

Thanks saxofaan. Will post there.

Ales' workaround looks good (and obvious w hindsight!)
Yet to try; tho will surely also mean not having comment form on same page as articles - lest anyone reading this thread doesn't know, to change from being on same page to separate page you can edit content type(s).

(just giving a better title to this thread and changing to feature request)

marked #676102: Add support for Varnish or other Reverse Proxy Cache as a duplicate. Interesting is that this thread refers to the same problem with mollom: #562374: Mollom incompatible with Pressflow's (and Drupal 7's) session handling -- causes CAPTCHAs to fail.

I don't have any extra caches turned on or installed and I still have the problem on Ubercart checkout.

Subscribe

Subscribe. No caching and same problem on user registration.

You can try to change the line 441 in captcha.module:

$solution = db_result(db_query('SELECT solution FROM {captcha_sessions} WHERE csid = %d', $csid));

works for me.

A note of caution about:

You can try to change the line 441 in captcha.module:
$solution = db_result(db_query('SELECT solution FROM {captcha_sessions} WHERE csid = %d', $csid));

FYI: the original code is:
$solution = db_result(db_query('SELECT solution FROM {captcha_sessions} WHERE csid = %d AND status = %d', $csid, CAPTCHA_STATUS_UNSOLVED));

If you change it to what sirozz suggests in #28, you open the gates for replay-attacks because a CAPTCHA session with solution can be reused as much as desired. (For at least one day: cron.php removes captcha session entries of 24 hours or older).

Normally, a CAPTCHA session can only be solved one time. This avoids replay attacks, but obviously does not play well with caching.

So be warned: if you're not afraid of replay-attacks, you could try the workaround of #28.

Subscribed, same here.

subs

Have been using math Captcha for more than 6 months without a problem, using just Imagecache and core Page cache control.

As of today it is impossible to use captcha since it denies math reply with: CAPTCHA validation error: unknown CAPTCHA session ID. Contact the site administrator if this problem persists.

Disabled core cache, run cron, emptied - but problem still persists (FF + Chrome). Had to disable CAPTCHA 6.x-2.1, for the time being.

@uno: if it stopped working 'as of today', what did change compared to "yesterday"? did you install other modules? run updates? other configuration tweaks/settings?

@saxofan - I changed nothing, there wasn't even a single module upgrade yesterday, it just stopped working, out of the blue, and I've notced it only during the evening wondering why there are no comments submitted.

I know you probably can't help my case, but I came here just wondering maybe something went wrong with module, generaly (altough it is not the most logical presumtion).

Luckily I was logged in while this happened, since I had math captcha on login form. I cannot imagine the pain of getting arround it while having this ID problem :)

Here's what log recorded:
Duplicate entry '740196' for key 1 query: INSERT into captcha_sessions (uid, sid, ip_address, timestamp, form_id, solution, status, attempts) VALUES (0, '62495965f53e78ea6d57027bf88c071f', 'myipaddress', 1264718104, 'comment_form', 'undefined', 0, 0) in /home/mysite/public_html/sites/all/modules/captcha/captcha.inc on line 92.

EDIT:
After I've emptied captcha sessions from mysql (2,7 MB) it started working again :)

#34 (emptying captcha sessions) didn't work for me

It looks like it's incompatible with any kind of caching except Drupal's built-in caching. i receive dozens of error every days. Shouldn't we make this critical?
I'm using 6.x-2.1 with Cache Router (File Based)
I'm going to try #12

For those of you in this issue that are having problems with ubercart and anonymous checkout
see #701908: Ubercart anonymous checkout fails captcha (add programmatic override)

It is a different issue to this one.

subscribe

Subscribe

I'm not using boost and i'm having this problem now too.

I would say this is pretty critical. I'm trying to put a captcha on a site-wide contact form (available for anonymous users) and need captcha. I'm also using cacherouter (maybe that's the issue?). Capctcha works fine on the login/register page but apparently is having a problem on a new webform install.

Since this has been open for a while and several people have said this is critical, I'm marking it as such.

We uninstalled Boost and turned off core caching and this problem still occurs. The captcha only works on webfroms when I click the submit button a second time.

ianchan, I was also using this with webforms. I ended up downgrading from webform 1.3 and then it worked. It could be a combination of something in webform 1.3 causing it if that's the version you're using.

subscribe

subscribe

subscribe

subscribe

I dont know if this is gonna solve this issue, but take a look at #745106: CAPTCHA validation error: unknown CAPTCHA session ID.

subscribing (will check back later)

I'm also having this issue. I do not have any extra caching except what is built into Drupal.

Looks like most of the stuff being blocked is spammers, so I definitely need it working. :)

subscribe

There's an issue in CiviCRM that gives this error. The CiviCRM form doesn't handle the Drupal CAPTCHA, or something like that. The thread is here:
http://forum.civicrm.org/index.php/topic,7303.0.html

After upgrading to the latest version, my seems to be fixed. I use Boost and Cache Router

Same issue here. No boost, no memcache, no ubercart - I'm using ONLY Drupal caching.

Captcha 6.x-2.2
ReCaptcha 6.x-1.4
Drupal 6.x-1.7

The change happened in the last 24 hours, but we have made no changes to the installation in at least a week. My captcha_sessions table is large (1500 rows or so). Cron doesn't change it, emptying the caches has no effect.

Can I just empty it, or is that really just a temporary solution?

We're getting slammed by "Duplicate Entry" errors, all instigated by line 92 of modules/captcha/captcha.inc
We're also getting slammed by "Incorrect Key" errors.

It was sudden. My paranoid mind wants to conclude that this is some automated bot since the same pattern has happened to others, but seemingly haphazardly over a rather large range of time (well, as indicated by this thread).

Any direction would be like gold - our users are getting frustrated.
;)

Chris

update:

Working with our host tech support, we discovered that the captcha_sessions table had crashed. Still no idea how or why. He repaired that table, I emptied it, and we're back in business.

Just in case it helps anyone else, the major watchdog errors were (I deleted the VALUES below):

Duplicate entry '411019' for key 1 query: INSERT into captcha_sessions (uid, sid, ip_address, timestamp, form_id, solution, status, attempts) VALUES (...) in /www/oursite.com/html/sites/default/modules/captcha/captcha.inc on line 92.

And:

Incorrect key file for table './opusdrupal/captcha_sessions.MYI'; try to repair it query: DELETE FROM captcha_sessions WHERE timestamp < 1279739702 in /www/oursite.com/html/sites/default/modules/captcha/captcha.module on line 152.

Other concomitant factors

1. There was an attempt to access a PHPMyAdmin installation on our domain. It was systematic - trying all version names as potential directories, etc.
2. There seemed to be a block of about 300 entries in captcha_sessions all from the same IP address for many different requests (I didn't ask for more detail).
3. cron.php did NOT clear captcha_sessions
4. clearing the cache did not clear captcha_sessions
5. we are only using Drupal's caching system - no others present.

Thanks to everyone who took the time to post their issues - it helped give us direction really quickly!
:)
Chris

subscribe. Seeing this.

Was having the same issue, however I also do not use boost, or any other caching module except the core.

Regardless of the type of validation i was trying to use, (math, recaptcha) i was getting the error.

Saw Yakker's post (#55) and proceeded to repair the captcha_sessions table using phpmyadmin. After doing this, the issue seems to have stopped & I am able to pass captcha's regardless of the validation method.

If it returns, I will post again, however I find it quite odd. Only one of my sites has experienced the issue, and it was directly after I installed captcha for the first time on this site.

As an aside, the first time I installed captcha on this particular site, the captcha_sessions table was never created. I re-installed & got the issue again, so I repaired the table. Is there something in the module that would make the table get dropped or not built?

~

We have experienced the same issue. I tried various fixes offered here and in the Webform issue queue under Webform not working with CAPTCHA, but none worked, not even turning off caching all together.

When I delved further into the module I found that the issue is with differences between the posted data structure captcha expects and the posted data structure webform uses. Because of this, no captcha session id was being recognized as passed from the form. The watchdog error message I had was "CAPTCHA validation error: unknown CAPTCHA session ID (NULL)".

I have created a patch that first checks if the standard array structure for captcha exists before using it, and if it doesn't it uses the webform structure. This was needed for both the captch session id (csid) and the captcha response. So the changed code looks like this:

  if (isset($post_data['captcha_sid'])) {
    $posted_captcha_sid = isset($post_data['captcha_sid']) ? $post_data['captcha_sid'] : NULL;
  } else { // Use webform array structure/sytnax
    $posted_captcha_sid = isset($post_data['add']['captcha']['captcha_sid']) ? $post_data['add']['captcha']['captcha_sid'] : NULL;
  }

This patch if for the current CAPTCHA version 6.x-2.2.

Subscribing, i have the same issue with hidden_captcha module;

The strange things is that seems like just spam comments get this issue, i've tryed all browser on all operative system and works well with all.

A reason more to hate spammers!

p.s: to everyone who cant disable captcha, try tye antispam module (with typepad), i guess its the best module (to use in conjunction with captcha) to fight spam.

An addendum to comment #18 is you need to dump your cache after making the change and let the system rebuild the cache while excluding your request.

I have also had experience with spammers not knowing how to fill out a comment form.

For example, if a human being fills out the form properly (re: enters the mandatory fields and then enters in something in the comment textarea) the comment issue talked about in this thread doesn't occur. If an automated script tries to brute its way through, the captcha system stops the comment from being posted but then the ID error occurs. Of course, this issue shouldn't be happening, but it also means captcha is doing the job but causes an error.

Of course, what the automated spam scripts are attempting to do is beyond my current research (mainly, I don't care) but I will see if I can can come up with some brilliant idea about why this is happening. I just want to put it out there that if the comments are being posted correctly and keeping the spammers out, it may help someone in the right direction for fixing it.

So it looks like at this point the only recommended workaround is to make your comment form show up on a separate page, and then exclude comment/reply/* from caching?

How was this solved for Mollom, when that module was made compatible with Varnish?

Also, I think this is a bug report, since there are so many people reporting this, and there are many circumstances in which people want to use caching besides standard Drupal page caching.

I think potentially this could be solved for Varnish using ESI (Edge-Side Includes), but that would be a rather advanced solution.

Hi, Subscribing, having same problem.
Greetings, Martijn

For me caching was a clear no-go in combination with captcha, I thought.
So I usually forced some alias' to keep static.

Now http://drupal.org/node/328143#comment-3548592 really helped for me- so I can use boost with CAPTCHA... (although I'm not using exact the same settings)

BUT I don't use varnish yet!?
Varnish has never been stable yet so I think we should be patient with that one for now.

Versions working for me:
- Drupal-6.19
- boost-6.x-1.18
- CAPTCHA-6.x-2.2
(and many more ... but not related here I think)

@R2-D8: Varnish, the software, is incredibly stable. I've had it run for weeks straight with no crashes. It is only the module which is still in dev. The module is not necessary for using Varnish the software - it just makes it so that your Varnish cache gets flushed on Drupal cache flush events, and I'm using it on several production sites with no problems despite it being in dev.

R2-D8, do you have your comment forms on a comment/reply page? It looks like those Boost rules exclude those from caching. I would imagine that would solve the issue; it's just that some people would like to have the comment forms actually on the same page with the original post. I think the way Mollom resolved this issue makes that possible.

I have been a little optimistic:

As I explained here http://drupal.org/node/328143#comment-3681320 :
Intensive testings resulted in the known problems.

In Short:
boost and captcha work together.
forms can be submitted.
BUT images and codes keep cached.

This means the same captha code keeps valid as long the site keeps cached.

I suggested excluding sensitive paths like contact and comment/reply/* (if public comments activated) from caching.

subscribe. It seems like the solution is a CAPTCHA that loads via JavaScript/Ajax for cached pages.

@Jonah Ellison: I think that would work, although would the submit handler be able to validate based off it? It might be a fairly big architectural shift for the module, though; I haven't looked at the code.

As far as excluding pages with comment forms on them from caching, that is a workable solution to the caching problem, but only if you have the comment form on its own page. Otherwise, you are defeating the purpose of caching, if comments are open on a significant number of your site's nodes. Thus, I believe some fix is needed, since people should be able to cache pages with comment forms, regardless of what form of caching is being used.

@Vako: Ah, so Boost is now using that workaround for this issue. I still think that is the incorrect way to do this, though. Mollom doesn't require it, afaik.

yakker: Many thanks. In our case, it was the crashed captcha_sessions table that cuased the issue.

Well, obviously we should first check the db first...

Even though captcha will disable caching of pages where forms are generated it still will cause problems when forms are generated in blocks. The boost captcha module will allow for the loading of the captcha using an ajax request and will prevent the captcha session expiry issue on statically cached pages with forms with captcha. Even though the module says boost captcha it should work for varnish or other page caching mechanisms as well.

Given that boost now prevents caching of pages with CAPTCHA, can we consider that this is no longer an issue and mark this as fixed?

I am marking this as outdated.