While i am using ajax dependant dropdown(hierarchical select) with captcha 7.x-1.3.
while populating dropdown it showing error.
"CAPTCHA session reuse attack detected."
after debugging i found in
function _captcha_get_posted_captcha_info($element, $form_state, $this_form_id){
}
During populating dropdown token values empty due to below code in captcha.module
line number 647
db_update('captcha_sessions')
->fields(array('token' => NULL))
->condition('csid', $posted_captcha_sid)
->execute();
so i put one condition for sort out this
if($form_state['submitted']){
db_update('captcha_sessions')
->fields(array('token' => NULL))
->condition('csid', $posted_captcha_sid)
->execute();
}
Please tell my anyone this is correct way or not.
Comment | File | Size | Author |
---|---|---|---|
#19 | captcha-n2474959-19.patch | 846 bytes | DamienMcKenna |
| |||
#1 | captcha-2015-06-09.patch | 669 bytes | egarbeil |
#1 | captcha-sesssion-reuse-error-2015-06-09.png | 96.14 KB | egarbeil |
e-Gov_AppStore_-_2015-04-21_10.57.32.png | 5.88 KB | fawwad.nirvana |
Comments
Comment #1
egarbeil CreditAttribution: egarbeil as a volunteer commentedI ran into the same exact issue after the 7.37 update on a client site. The client is using CRM core and CRM core donation with commerce. They received this error on their donation form after the update. The trigger was any change of payment method on commerce checkout form (embedded) - See file image (captcha session-reuse-error.png). below. There were no issues before the 7.37 update. That was the only change (core 7.36 to core 7.37). The above fix solved the problem and I did not have to remove the captcha from those pages. Please add this patch to the captcha module (on my version it is added to line 637).
Versions (relevant modules):
core - 7.37 *** this was the only change (from 7.36 to 7.37)
drupal commerce - 7.x-1.11
crm core - 7.x-0.980
crm core donation - 7.x-1.14
crm core profile 7.x-1.0-beta10
crm core profile commerce items - 7.x-0.4
entity api - 7.x-1.6
entity reference - 7.x-1.1
Comment #2
detroz CreditAttribution: detroz commentedIt works for me.
I'm using it with recaptcha and this patch : https://www.drupal.org/node/2449209
Thanks.
Comment #3
dzy CreditAttribution: dzy commentedusing hs + CAPTCHA , same problem. 1# patche works.
Comment #4
alesr CreditAttribution: alesr commentedPatch #1 worked for me too on Drupal 7.39 using Captcha 7.x-1.3.
Can we get that commited to captcha 7.x-1.x-dev?
Comment #6
alesr CreditAttribution: alesr commentedFixed #1 to have another try with the testbot.
Comment #7
alesr CreditAttribution: alesr commentedForget #6. It includes the original patch in it too.
Fixed in #7.
Comment #8
wundo CreditAttribution: wundo at Chuva Inc. for Chuva Inc. commentedI will need a test to check this scenario before committing, this is the sort of issue that we need to be safe before committing, could you update the patch to add the test scenario as well?
Cheers,
Fabiano
Comment #9
joewhitsitt#7 applied cleanly and works for my situation which includes an ajax file upload component.
drupal-7.39, webform-7.x-4.11, captcha-7.x-1.3, hidden_captcha-7.x-1.0
Comment #10
djpable CreditAttribution: djpable as a volunteer commentedDoesn't work for me.
Works but make me submit even with an erroneous captcha...
does this happen only to me ?
Comment #11
jastraat CreditAttribution: jastraat at Technivant commentedHave you tried the patch in #1395184: Forms with AJAX trigger "CAPTCHA session reuse attack detected." error?
Comment #12
PapaGrandeI can confirm that the fix from #1395184: Forms with AJAX trigger "CAPTCHA session reuse attack detected." error does fix this error for me, and it's already been applied to the dev version of the module. This issue may be a duplicate.
Comment #13
AnybodyComment #14
vadivel82 CreditAttribution: vadivel82 commentedIt is working for me
if($form_state['submitted']){
db_update('captcha_sessions')
->fields(array('token' => NULL))
->condition('csid', $posted_captcha_sid)
->execute();
}
Thanks
Comment #15
kiwimind CreditAttribution: kiwimind commentedI've just tried the -dev version and the error is still showing, so I think this issue and patch is still relevant.
The patch in #7 applies to the -dev version, so could do with going via the testbot again.
Otherwise, I'm happy to RTBC, as it works as expected for me.
Thanks.
Comment #16
DamienMcKennaComment #17
Dima DD CreditAttribution: Dima DD as a volunteer commentedSorry, I'm a beginner level user and my interpretations may be wrong.
Recently (1-2 weeks ago), I've noticed that spam-bots have started to reuse old sessions somehow(?). According to logs, they gave answer (incorrect but close to) while the program reported about inconsistent correct solution (probably value of incorrect type), like this:
user_register_form post blocked by CAPTCHA module: challenge Image (by module image_captcha), user answered "6zmsety", but the solution was "07737bf0f10775e92eefc29ac22084dd".
In many cases, record of this type is followed by immediate successful registration of spam-bot.
This small patch (form state checking) have solved this problem and dramatically decreased log records about registration attempts from spam-bots.
Thank you!
Comment #18
mattgross CreditAttribution: mattgross commentedSuccessfully applied the patch in #7 to the 7.x-1.3 version of the module.
We're using it on a webform with multiple pages and a multiple-file upload field. It looks good so far.
Comment #19
DamienMcKennaDoes this also solve the problem? I improved the logic slightly around the variable check.
Comment #20
MaskOta CreditAttribution: MaskOta commentedThis problem also exists in D8. In our case it happens when trying to upload an image to a form(using the entity browser).
Comment #21
MaskOta CreditAttribution: MaskOta commentedAttached patch is against the latest d8-dev. I have no idea if this solution is any good.
Comment #22
koppie CreditAttribution: koppie at Exygy for Cohere commentedGuys . . . this thread has a versioning problem. The OP mentioned the stable release (1.3) but the issue metadata says dev.
I can confirm that upgrading to the latest dev version solves the problem.
We haven't had a stable release of this module since 2015, so hopefully we'll get one soon. In the mean time, I recommend marking this issue as fixed.
Comment #23
sudheeshps CreditAttribution: sudheeshps at TATA Consultancy Services commentedAttaching new patch that will work with version 1.4
Comment #24
DamienMcKennaPatch #23 doesn't include part of the if() statement from #19, so I suggest just sticking with #19.
Comment #25
Utkarsh Harshit CreditAttribution: Utkarsh Harshit at SDG Corporation commentedcaptcha_session_reuse-2474959-7.patch
This worked for me......thanks
Comment #26
DamienMcKennaI don't want to RTBC my own patch, but we've had great success with #19 on several production sites.
Comment #27
MaskOta CreditAttribution: MaskOta commentedPatch in #19 fixed the problems for us. I guess ill RTBC then
Comment #28
elachlan CreditAttribution: elachlan commented#19 seems ok but Wundo was after some tests to help detect the issue.
Could someone look at writing a test for this scenario?
Comment #30
umpire274 CreditAttribution: umpire274 as a volunteer commentedIn my installation the solution #19 fixed the problem. Thanks.