Captchas sometimes throw a validation error and say:

CAPTCHA validation error: unknown CAPTCHA session ID

There are a few potential reasons and workarounds, but one current solution is in another issue.

Proposed solution:

Try the proposed code change in #3089263: Captcha Session ID broken with cacheable captcha backends. It is a merge request and is available as a patch

Original report:

I know this bug has been reported and fixed before, but after installing Drupal 8.6.10, I was unable to get into my site as admin, using several browsers. I had to remove reCAPTCHA using composer to get in.

Issue fork recaptcha-3035883

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tjtj created an issue. See original summary.

hass’s picture

Status: Active » Closed (cannot reproduce)

There is no v3 version.

FiNeX’s picture

Hi, the bug is reproducible with the v2 version. I'm currently having on a D8 website with latest D8/Webform/Captcha/reCaptca. The webforms are embedded into nodes using paragraph with entity reference fields. Drupal cache is disabled.

FiNeX’s picture

Status: Closed (cannot reproduce) » Active
FiNeX’s picture

Hi, the bug is still reproducible on D8. Until Captca/reCaptcha are not reliable shouldn't a warning be added on the module pages to inform that the module is not ready for production environment? Thanks.

hass’s picture

Status: Active » Closed (cannot reproduce)

This module is ready for production.

FiNeX’s picture

Not in my experience, there are several issues and I've been forced to remove this module on websites with multiple forms on the same page, for example, moreover this bug is blocking a lot of requests on a customer website... just to say.

brentmeuleman’s picture

I still get this issue, several times.
Client can't log in this way.
We are using the v2 version of recaptcha.

Engineer_UA’s picture

Guys, any ideas regarding this issue?
There is a problem between caching and reCaptcha module. I encountered this problem on my WEB-site twice during last week.
And after clearing the cache with "drush cr" reCaptcha starting to operate in normal mode.

caspervoogt’s picture

This module has been reliable for me since Drupal 8 came out, but the last few months I have been dogged by continuing issues with the 2.x-dev version, e.g. "unknown CAPTCHA session ID". I am using it on the Drupal login form, and there is caching enabled. I think this Captcha module issue might be related; https://www.drupal.org/project/captcha/issues/3032742.

Lantzr’s picture

We were getting the same error yesterday on D8/webform.

CAPTCHA validation error: unknown CAPTCHA session ID. Contact the site administrator if this problem persists.

Flushing cache resolved temporarily but we assume the underlying problem (whatever it is) still exists.

sinn’s picture

We have this issue with pages cached by Varnish when captcha_cron removes captcha_session that are stored one day only.

It was decided to remove captcha session validation:

// Wrong code has been removed.

Captcha setting "Persistence" should be set as "Default" as we can't rely on IP of client anymore.

JeroenT’s picture

I had the same problem. I used Captcha and Recaptcha in combination with webform.

When I switched to the default (math) captcha, everything worked fine.

To reproduce this error:

  1. Create a webform, and add recaptcha to it.
  2. Visit the webform page, fill in the webform, and submit. The submission was made successfully
  3. When you visit the webform page again, there are no longer records added to the "captcha_sessions" table.
  4. Truncate the captcha_sessions table.
  5. Fill in the webform again.
  6. You now get an error: "CAPTCHA validation error: unknown CAPTCHA session ID. Contact the site administrator if this problem persists."
sokru’s picture

Version: 8.x-2.x-dev » 8.x-2.4
Component: reCAPTCHA V3 » reCAPTCHA V2
Status: Closed (cannot reproduce) » Active

Happened today with 8.x-2.4. As mentioned clearing cache helped as a temporary solution.

agoradesign’s picture

having the same issue

agoradesign’s picture

btw, I've implemented the workaround in #12 - beware, that you should also check for the "default" captcha_type, if reCAPTCHA is your default one

vincentdemers’s picture

I use a site with cache enabled. This issue occurs after +/- 2 days after clearing the cache.

For me implementing the fix in #12 disables captcha validation entirely, users can register without checking the recaptcha checkbox at all.

I have tried to implement the patch in #10 without success. The issue still occurs after 2 days of running the website without clearing the cache.

I am using recaptcha 8.x-2.4+1-dev and captcha 8.x-1.0-beta3+15-dev.

I am switching back to math capctcha and will be following this thread.

Vincent

sinn’s picture

Yes, solution #12 is wrong a little bit )). We have fixed it already. Here it is:

use Drupal\Core\Form\FormStateInterface;

/**
 * Implements hook_element_info_alter().
 */
function MODULE_element_info_alter(array &$info) {
  if (isset($info['captcha'])) {
    // Adds custom process function to captcha element.
    $info['captcha']['#process'][] = 'MODULE_element_captcha_process';
  }
}

/**
 * Removes 'captcha_validate' for reCaptcha.
 *
 * For this captcha type check of captcha session doesn't needed because
 * solution is stored in reCaptcha service. Also it resolves issue with cached
 * by Varnish pages.
 * Note: some degradation of captcha module will be - statistics
 * won't work but it is disabled on this project.
 */
function MODULE_element_captcha_process($element) {
  $default_challenge = \Drupal::config('captcha.settings')->get('default_challenge');

  if (!empty($element['#element_validate'])
    && ($element['#captcha_type'] == 'recaptcha/reCAPTCHA')
    || ($element['#captcha_type'] == 'default' && $default_challenge == 'recaptcha/reCAPTCHA')) {
    foreach ($element['#element_validate'] as $key => $value) {
      if ($value == 'captcha_validate') {
        $element['#element_validate'][$key] = 'MODULE_recaptcha_validation';
      }
    }
  }
  return $element;
}

/**
 * Replacement of captcha_validate() function.
 */
function MODULE_recaptcha_validation($element, FormStateInterface &$form_state) {
  $result = recaptcha_captcha_validation('', '', $element, $form_state);
  if (!$result) {
    $form_state->setErrorByName('captcha_response', t('The answer you entered for the CAPTCHA was not correct.'));
  }
}

vincentdemers’s picture

Hello Sinn,

Thanks for the quick response.

I have updated my custom module with your new code. My new module name is recaptcha_session_fix.

When I try to register on my site I get the following error:
TypeError: Argument 2 passed to recaptcha_session_fix_recaptcha_validation() must be an instance of FormStateInterface, object given in recaptcha_session_fix_recaptcha_validation()

Can you please enlighten me as to what I may be doing wrong?

Vincent

vincentdemers’s picture

Answering myself:

Adding these two lines at to the top of my .module file fixed the issue

use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;

I will be reporting here again if the session id issue persist with the fix in #18

m.lebedev’s picture

I have same problem

jlab’s picture

I also run into this issue. to the point where I have to drop this module until there is a fix because our clients are complaining. Is there anything we can do from our side to help the issue along?

davemanroth’s picture

I'm having the exact same problem too: validation error due to unknown CAPTCHA session ID. I clear the system cache which works for 2-3 days, then the message returns. Going to try to use the custom module code from comment #18. Thank you for posting this, hopefully this will be fixed soon.

neclimdul’s picture

I've been struggling with this, randomly having the same failure sneak up and break our site. I think I've narrowed this down to the cacheability support in captcha and the only reason this affects recaptcha is it is trying to use that feature in captcha. This aligns with the "fix" module in this issue which bypasses the the session validation entirely when using recaptcha.

I've opened an issue against captcha #3089263: Captcha Session ID broken with cacheable captcha backends where I've started documenting this and working on a fix. I think something along the lines of the module in this issue converted to use the cacheability of the captcha backend is probably the fix since I don't think its ever really going to work with cached form renders.

With all that said, while reCaptcha _could_ apply this sort of fix I think its something captcha just really needs to fix since its a bug in the underlying API.

agoradesign’s picture

great! thanks for the patch @neclimdul.. Is that $captcha_info['cacheable'] already set by reCAPTCHA, so that applying that patch should work already?

neclimdul’s picture

Correct, reCAPTCHA sets itself as "cacheable" which is why it is failing and why switching to say "Math" which is not cacheable fixes it.

agoradesign’s picture

should we post a workaround patch to unset recaptcha as being cacheable, as long as #3089263: Captcha Session ID broken with cacheable captcha backends is not solved?

agoradesign’s picture

FileSize
554 bytes

ok, here's a workaround patch for anyone, who wants to avoid recaptcha being cacheable, as long the captcha module bug isn't fixed

agoradesign’s picture

FileSize
620 bytes

forget #28, use this one instead

effortDee’s picture

I am having this on one of my sites, how can I log in and remove the module, clear cache?

droddis’s picture

@agoradesign thanks for the patch, can you clarify if this is targeting 8.x-2.x-dev or 8.x-2.4?

thanks in advance,

Dave

caspervoogt’s picture

@effortDee use Drush and this command: "drush uli". You can use that to log back into user 1's account. You can also use Drush to do "drush pm-uninstall recaptcha", which might be better.

caspervoogt’s picture

the patch from #29 works for me and applied cleanly to 2.4.

agoradesign’s picture

@droddis
it is written against dev, but also applies to 2.4 (like @caspervoogt approved)

gallegosj’s picture

@agoradesign Would it be better practice to apply the #29 patch or to downgrade to CAPTCHA 8.x-1.0-beta1?

agoradesign’s picture

That's a matter of personal taste. I don't have an overview over the other changes made in captcha since beta1, if there's something really important inside. Also I'd say that, if there were database updates in between, I'd rather stick to patching, because you'd have to revert the update changes as well otherwise

effortDee’s picture

I'm not using drush, how can I log in to my site and fix this issue?

EricVL’s picture

@effortDee.
If you have ftp access, you could change your settings.php file and add this line:
$config['user.role.anonymous']['is_admin'] = 'true';

Probably you have to change the access rights of the file and the directory first before you can change it and set the site in servicemode.

This extra line gives admin rights to an anonymous user. So you have admin rights when do not login.
Change the setting of captcha to the default (no recaptha) and remove the extra line in your settings.php file (or comment it out).

Try to login with your standard admin account.
Good luck

droddis’s picture

@effortdee If you access the database and clear all cache tables, and your captcha sessions table it will solve the issue and allow you to log in. I just go in using phpMyAdmin from my servers backend.

effortDee’s picture

Thank you so much for your explanations EricVL and droddis.

I'm in and captcha module is not on login forms any more.

Good thing it's only a small test site.

have a great day!

TheMarigane’s picture

I think to solve this problem we just need to clear drupal cache with cid:captcha_placement_map_cache
at the end of each cron execution.
May be with use of CacheBackendInterface or directly drush command

ranjan.daswani’s picture

#39 is working for me.

Metztli’s picture

#29 Worked for me, as well, as I was experiencing 'CAPTCHA validation error: unknown CAPTCHA session ID (xyz)' under Drupal 8.8.0.

I patched recaptcha 8.x-2.4 Stable [] released 31 January 2019, which enabled contact form to successfully mail the message(s).

Thank you!

joachim’s picture

This patch shouldn't be needed with the patch from #3089263: Captcha Session ID broken with cacheable captcha backends.

agoradesign’s picture

@joachim.. but what about #3089263-10: Captcha Session ID broken with cacheable captcha backends? I'll comment on the other issue more detailled

goodDenis’s picture

#39 is working for me.

goodDenis’s picture

#39 is working for me, but only for some time :(
#29 fix the problem, thanks!

bdupls’s picture

#39 worked for me. Adding sample script for those who need it, obviously my install.
TRUNCATE cache_bootstrap;
TRUNCATE cache_config;
TRUNCATE cache_container;
TRUNCATE cache_data;
TRUNCATE cache_default;
TRUNCATE cache_discovery;
TRUNCATE cache_dynamic_page_cache;
TRUNCATE cache_entity;
TRUNCATE cache_menu;
TRUNCATE cache_page;
TRUNCATE cache_render;
TRUNCATE cache_toolbar;

miro_dietiker’s picture

We also needed to apply this patch since site registrations didn't pass anymore (after a first successful test).

The module can cause quite some harm with such behavior and it's an annoying trap since a single test doesn't identify the bug.

Is there maybe a way to reproduce the bug with a test?

joachim’s picture

Please see #44. This is the wrong fix -- the problem is in CAPTCHA module, not here!

kacash’s picture

As agoradesign warned in #16 although ReCAPTCHA was my default, the individual forms were set to use the vanilla CAPTCHA at /admin/config/people/captcha/captcha-points. Once I switched those the validation errors stopped. (The cache flush worked for me too, but only temporarily.)

fomenkoandrey’s picture

drupal 8.8.1 the same error with ID captcha

fomenkoandrey’s picture

drupal 8.8.2 ID captcha error
http://prntscr.com/r01ccm

skouf’s picture

For the moment, I had to disable the recaptcha test and use the Math validation.

Emptying the cachetags database resolved the problem and I was able to connect to drupal. But I can't do that each time.

I will follow this issue until a working patch is posted.

Thanks !

asilva3’s picture

running drush cr helped temporarily, allowed me to log in again and change my validation settings. I will follow this issue as well until a stable patch has been made.

Ananda’s picture

Sorry, I can't believe this ...
Such a basic module "Google Recaptcha", and I also experience those same issues.
Drupal has far more bugs then Wordpress, that's why this is sometimes a Drupal-Hell.

It's a pity

Ok, I know people work on this for free, so I can't complain...
I'd love to pay for this module if it just worked !

Not all modules are ported to Drupal 8, and the bugs are immense, but hey, let's switch already to Drupal 9 in november 2021.

agoradesign’s picture

wow, very constructive comment

sbasile’s picture

I am still seeing this issue too using CAPTCHA 8.x-1.0 and reCaptcha 8.x-2.5 on Drupal 8.8.2. I'm trying to determine from this thread if the patch in #29 is necessary or not. Thank you.

gallegosj’s picture

@sbasile I applied patch #29 back in November and have had no problems ever since.

agoradesign’s picture

I use that workaround still myself, but the more people have time to test patches from https://www.drupal.org/project/captcha/issues/3032742#comment-13364556 and https://www.drupal.org/project/captcha/issues/3089263#comment-13387218, the sooner we will have a better solution

dickensas’s picture

I manually deleted the modules "captcha", "recaptcha" and deleted the configs from the config table and truncated all the cache tabled
then re-installed the latest modules
8.x-1.0 Stable release covered by the Drupal Security Team released 21 February 2020
8.x-2.5 Stable release covered by the Drupal Security Team released 29 January 2020

now it is working

agoradesign’s picture

@dickensas without patches? impossible!

It was btw a very unfortunate decision of the captcha maintainer to tag a stable 1.0 release without having this major bug fixed. This will end up in a bad surprise for many users

droddis’s picture

Hey @agoradesign, I'm a bit lost in trying to follow all the patches and issues. i've ended up reverting to Math based Captcha's, obviously not ideal. Can you outline what patch/module combinations you are using to get around these issues?

Cheers,

David

agoradesign’s picture

Hi David,
captcha module has currently two problems that can hit you, when using reCaptcha. One only occurs in some edge cases, because session information may be cleaned up too early - which only make problems, if there's a really long interval between opening form and submitting it. I personally normally don't include this patch, although it's a tiny and easy one: #3032742-6: captcha_cron() removes captcha_sessions that may still have open PHP sessions

The bigger one is the current inability to handle cachable captcha backends such as reCAPTCHA. Patch #3089263-24: Captcha Session ID broken with cacheable captcha backends has solid unit tests proving its functionality. There are also comments approving that this fix is working. So this patch should have all you need.

However, if you don't really care about whether your receptchas are able to be cached and want absolutely no risk that this error still can occur, you may also want my workaround patch from comment #29 of this thread, which simply turns off cacheability of recaptcha module. I still use this in many projects, but the main reason is that I haven't really spent time in observing and testing this issue. This combination landed once in my composer builds and I'll continue to use it, until #3089263: Captcha Session ID broken with cacheable captcha backends is finally committed and fixed

dickensas’s picture

Hi @agoradesign it is working here http://dickens.co.in/user/login drupal 8.8.0

--EDIT--

I take back above comment, it stopped working after 4 days
I went for image recaptcha V3 https://www.drupal.org/project/recaptcha_v3

agoradesign’s picture

@dickensas

the problem with this bug is, that you don't see it immediately / on every request, as it's related to caching and sessions.

thx for the feedback. To avoid any misunderstandings: as per #61 you wrote, that you didn't apply any of the recommended patches, right? Then it's logical that it won't work. But if you applied patches and still didn't work, please provide detailed infos, which patch(es) you have applied. Would be a big help in getting this done asap

gobnat’s picture

a) would #3089263: Captcha Session ID broken with cacheable captcha backends also effect Recaptcha V3?

and

b) Assuming I roll out the patches from #64 discussed by @agoradesign how do I test it isn't happening again given how erratic and how long it takes to appear? I cannot tell my users to just wait a few days and see what happens.

Joe Huggans’s picture

This problem still seems to exist with version 2.5, can anyone advise on the best way forwards with this, the patch at #29 will not apply, has a permanent solution been found?

iuana’s picture

I am also facing the same issue using the 2.5 version of the module. I applied the patch form here https://www.drupal.org/project/captcha/issues/3032742 from the #6comment.
It disappeared for a while but it continues to appear without knowing under what circumstances.

I will continue to follow the issue and also to figure out what are the steps to reproduce.

c_westermann’s picture

Hello. I am facing the same issue. I am currently blocked from accessing two of my sites. As I am more of a designer than a system administrator, I would be grateful if someone could tell me if there is a simple way to gain access to my sites again. I do have shell access, I also have PhpMyadmin access. I do not have drush installed and would be grateful if there was a simpler way. Many thanks!

droddis’s picture

Hey there,

In my experience if you log into PHPMyAdmin and empty the Sessions and Captcha Sessions table, and clear the cache tables you should be able to log back in to the sites.

#not responsible if it goes pear shaped :) take backups but I've had to do this a number of times and it has been fine. Please note if you have active users on the site I'm pretty sure this will dump their session info as well, so something to consider before doing this.

KlemenDEV’s picture

This bug is very troublesome not only for cases where the user gets blocked out of the website, but also in cases where forms are protected by CAPTCHA and users are not able to submit these forms. I have to constantly monitor forms and clear caches when this occurs.

This makes this module essentially useless as it does more harm than good.

Joe Huggans’s picture

For what it is worth I have setup cache to clear on cron and I'm running cron every 15 minutes.

alex0412’s picture

If it helps anyone: my workaround was to downgrade/lock captcha and recaptcha modules to a version before the bug was introduced:
drupal/captcha 1.0.0-beta1
drupal/recaptcha 2.5.0

I'll update once the bug is fixed.

KlemenDEV’s picture

I can confirm downgrading is needed or patching the ReCaptcha module to not declare itself as a cacheable CAPTCHA.

c_westermann’s picture

@droddis Many thanks. This worked for me. Much appreciated!

spiralarts’s picture

You can log in to your website by going to your login path and reset the password. With the link you'll receive in your admin email you can log in and disable the captcha module or update it if it's outdated. (worked for me)

pipicom’s picture

Can confirm that #29 works for me with reCaptch 8.x-3.0.

friolator’s picture

What are the chances of this fix being implemented in a stable release soon? It seems to work for people who have tested it. We had to revert to a simpler image captcha and our site is flooded with spammers now. But recaptcha was just too unreliable, generating validation errors more than 50% of the time.

bas123’s picture

Yup, #29 did the trick!

Thanks

maseyuk’s picture

Something must have suddenly changes on google recaptcha's side I reckon. As I'm getting this error on sites that have been using the same captcha/recaptcha module version for over 6 months and it's only suddenly happening now

Applying the no cache patch from #29 does the job as a quick fix though

awasson’s picture

Also am noting captcha fails today. The patch on #29 would not apply to my copy of reCAPTCHA 8.x-2.5 but I changed the two lines manually and all is well.

Unless there is a better fix, I think #29 should be rerolled against Dev-8.x-2.x and applied because this is affecting all of the D8 sites I use ReCaptcha on and I'm sure it's not just affecting me.

Michele Bertani’s picture

With #29 enabled everything is going normally.

i understand it's a workaround, but we have this kind of cache-related issue for a long time now, theres no fix applicable?

Michele Bertani’s picture

We are using stable releases, not the dev branch

droddis’s picture

Does anyone know if this is solved in 8.x-3.0?

@Michele Bertani did you apply this patch to 3.0?

Michele Bertani’s picture

@droddis nope, i've applied to 8.x-2.5 branch, i've not yet moved to 3.x release, sorry

kevinquillen’s picture

Version: 8.x-2.4 » 8.x-3.0

This message is appearing on a brand new site on 8.9.5.

What are the proposed steps to resolving it? It is a single webform with reCaptcha attached.

lunk rat’s picture

Priority: Major » Critical
droddis’s picture

This message is appearing on a brand new site on 8.9.5. What are the proposed steps to resolving it? It is a single webform with reCaptcha attached.

Hey @kevinquillen,

Loved seeing your name here given all the huge help you provided me years ago on a few RETS feed sites! In my experience the only fix has been to stick with version 2.4 of Recaptcha and using the patch supplied above. Every other configuration of releases of Captcha and ReCaptcha have resulted in a full cache of submissions, and then the error.

I would revert to Recaptcha 2.4 and patch it, unless you want to take on fixing this for the rest of us! I'd offer to help but it's a bit beyond my skillset. But I'm happy to help test or whatever else may be useful.

kevinquillen’s picture

We had many sites already live and in flight, this was blocking forms of a lead generation nature. We wound up removing it and putting Honeypot in its place, could not afford the time to downgrade and wait a few days to see the result(s). The issue was hard to replicate, but we did occasionally get this error to appear on Acquia. We also would get weird errors in Google about Google being unable to verify the site was verifying challenges, though it appeared to be doing so.

droddis’s picture

Did you tweak the Honeypot settings to reduce spam? Even with Captcha's and Honeypot we have some sites with significant spam. If you have any tips or suggestions on Honeypot settings that provide adequate spam protection/reduction I'd love to hear them. We use 6 seconds and a random work for the honeypot field.

thanks in advance,

rgpublic’s picture

I can highly recommend AntiBot (https://www.drupal.org/project/antibot). We switched many sites from Recaptcha to AntiBot due to this bug and GDPR concerns and were very happy with the results.

sbasile’s picture

Is there a reason why this patch is not in the latest version? This issue showed up again in one of our sites.

nguyenphan’s picture

It also appear on my website drupal 9.06 and recaptcha 8.x-3.0. Temporary i switch to use match captcha as default.

mebel192’s picture

i wait for a definitive patch before using reCAPTCHA v2 as a fallback of reCAPTCHA v3. if someone can merge patch :)

akalam’s picture

greggles’s picture

Issue summary: View changes

Updating the issue summary in the hopes it saves people some time.

DeFr’s picture

Issue summary: View changes

Note: the .patch URL on the MR only provides the patch for the first commit of the MR. Tweaked the issue summary to point toward the .diff , which does include the diff from all the commits.

greggles’s picture

Thanks, DeFr!

akalam’s picture

greggles’s picture

I think it's good to keep this open until that is committed. That will help people to find that issue.

spidersilk’s picture

I'm encountering this error too, and it's blocking me from being able to log in to the site. I tried emptying the cache tables via phpMyAdmin as recommended by some comments here, and that actually made it worse — instead of getting the CAPTCHA validation error displayed on the login page, now when I submit the login form I get a white screen with "The website encountered an unexpected error. Please try again later."

And the error log records the following:

Error: Class 'ReCaptcha\ReCaptcha' not found in /home/dcarpetca/public_html/modules/contrib/recaptcha/recaptcha.module on line 162 #0 /home/dcarpetca/public_html/modules/contrib/captcha/captcha.module(501): recaptcha_captcha_validation('1', 'Google no captc...', Array, Object(Drupal\Core\Form\FormState))

Any ideas? I'm pretty much ready to remove ReCaptcha entirely at this point, but I need to be able to get in to uninstall it...

Update: I eventually deleted the module with Composer, so now the site is working again — I'd been worried that doing that without being able to uninstall first would cause database problems, but apparently not!

greggles’s picture

Folks should just use the patch in #3089263: Captcha Session ID broken with cacheable captcha backends. See the issue summary. Deleting modules without uninstalling them can cause problems in the long run, but they are usually subtle and not fatal problems.

thalemn’s picture

@spidersilk: instead of removing the module via composer, I renamed the captcha and recaptcha module folders (captcha_disabled and recaptcha_disabled). Consequently I was able to login to my site and then I renamed the modules back to original names, and then uninstalled the modules via the backend admin extend interface.

As for everyone else, since I just landed here today, I see both captcha and recaptcha issues are still not marked resolved. So I'll just leave the modules disabled on my site for now and wait for the experts to push the patches to new version releases. Then I'll run composer update and life will be good.

agoradesign’s picture

#3089263: Captcha Session ID broken with cacheable captcha backends is resolved and captcha 1.2 released. If anyone can confirm that this also solves this problem without needing an extra fix for recaptcha, we could close this issue!

droddis’s picture

@agoradesign

So just upgrade all Recpatcha and Captcha versions and let it run for a bit? I can do that on some sites and report back.

So Captcha 8.x 1.2 and reCaptcha 8.x-2.5?

Does anyone have any sense of how many sessions end up breaking the ReCaptcha tool?

greggles’s picture

Category: Bug report » Support request
Status: Active » Fixed

@droddis, yes, that combination should work. IMO this is "fixed" from the perspective of reCAPTCHA and since the bug was in CAPTCHA module, I've reclassified this as a support request.

droddis’s picture

@greggles

Thank you so much. I'll roll this out across 20 or so sites as a test and let you know if I see any issues arising. I know the patch has been a great interim solution, but it will be nice to get everything on solid releases again.

thanks for all the help and support.

Cheers,

David

agoradesign’s picture

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

jlstrecker’s picture

Is this bug not fixed by Captcha 1.2, or is my team seeing a different bug, or have we misconfigured the Recaptcha module?

If I understand correctly, in order to avoid the "CAPTCHA session reuse attack detected" error, the captcha token in the HTML should be different on each page load. If I run a command like this…

$ curl -s https://example.com/page | grep captcha_token

… then I get something like this …

<input data-drupal-selector="edit-captcha-token" type="hidden" name="captcha_token" value="ZAU2RkfBGi618DOR5_B1tQrQhG7TaiHHbjJzNbWhd6c" />

Running the command repeatedly should give a different value each time, right?

That's not what we're seeing with Captcha 1.2 and Recaptcha 3.0. Tested on a fresh Drupal 9.2.2 site:

  • captcha 1.2 (no patches), built-in "Math" captcha — ✅ token changes each pageload
  • captcha 1.2 (no patches), built-in "Image" captcha, drush cr — ✅ token changes each pageload
  • captcha 1.2 (no patches), recaptcha 3.0 (no patches), drush cr — ❌ token remains the same
  • captcha 1.2 (no patches), recaptcha 3.0 with 3035883-29-workaround.patch, drush cr — ✅ token changes each pageload

Only with 3035883-29-workaround.patch does Recaptcha generate a different token on each page load.

The problem does not happen on sites that have Honeypot installed, since that module triggers page_cache_kill_switch. If other people are seeing different behavior, that might explain why.

DYdave’s picture

Hi @jlstrecker,

Thanks a lot for your detailed tests and feedback, it's greatly appreciated.

Just wanted to let you know I have tested again the issue and was unable to reproduce the error.

I have been testing with:

  • Drupal core 8.9.17
  • Captcha: 1.2
  • Recaptcha: 3.0

Which corresponds to your testing case 3:

captcha 1.2 (no patches), recaptcha 3.0 (no patches), drush cr — ❌ token remains the same

I can confirm the token indeed stays the same, I have been getting:

<input data-drupal-selector="edit-captcha-token" type="hidden" name="captcha_token" value="1xzbvPt5svweVO7bxgGoVKyvW5vxKViC0n2GL7p7P9Q" />

I tried testing with recaptcha on login page: logging in/out with multiple users (different roles) and wasn't able to reproduce the error.
I confirmed each time page's code contained the same token (from HTML code above).
Testing with different browsers, with/without private/incognito windows (disabled caching, cookies and such), and changing IP address during the process.

I also tried reproducing the steps from #13, with a captcha component in a webform.

Still couldn't reproduce the error.

Not sure if I missed anything while testing or would need to change anything else in the configuration or testing process, but I was unable to prompt out any errors.

So if anyone is still having this problem with the indicated versions of the modules, it would also be greatly appreciated if you could please provide the steps to test and reproduce the issue.

Thanks again very much @jlstrecker for sending your feedback with a clear breakdown of your tests.
Cheers!

jlstrecker’s picture

@DYdave, thanks to you also for your testing.

> I can confirm the token indeed stays the same

With multiple users, won't that lead to the "CAPTCHA session reuse attack detected" error?

To be clear, the steps that I posted do not directly trigger the "CAPTCHA session reuse attack detected" error. They only lead to the token being the same on successive page loads, which (if I understand correctly) creates the right conditions for the "CAPTCHA session reuse attack detected" error to occur.

Or is it somehow OK for the site to serve the same CAPTCHA token to different users? (If so, why?)

ajrepullo made their first commit to this issue’s fork.