The captcha system on my site has developed a peculiar bug that I can't seem to resolve.

The captcha image that is displayed is different to the captcha code that is required, so it always says code not verified.

I added some additional watchdogs to the module to try and help diagnose it, and the output routine to add the image to the page is being called once, but the code to generate the image is being called twice. It looks as though the image being output is the result of the first process, but the code that is being used for comparison is the result of the second.

I am puzzled as to why this is happening.

Also, more bizarrely, it only seems to be problem under Internet Explorer.

Has anyone else experience anything like this? I have tried disabling any modules that I've added recently and it doesn't appear to be related to that.

Thanks.

Comments

Stuart Greenfield’s picture

This was bugging me (no pun intended!) so I added some more watchdog lines. I don't think my description above is quite right (I must have put a line in the wrong place!)

What DOES seem to be happening is that if you enter the wrong code a new captcha image is generated, with a new code word, but the session variable ($_SESSION['captcha']), although it initially updated when the image is generated, still has the original codeword when it comes to validation!

So the validation fails because the words don't match.

As a work around I've made it so the code word doesn't change once its been generated - it just prompts the user to try again.

Question is still whether anyone else has experienced this?

Julian Ivanov’s picture

Hello, i have similar problem with COPTCHA on my own framework, first i think that this is becouse of IE`s policies, but afther I create P3P Policy and validated it and nothing changed, I change the way my URL is, ie.

I have Login, module, and the form is submited via <form method='post' action= '/Login/Proceed'>, when user enter some incorect data, he is returned to the login screen with warning, but the uri become /Login/Proceed, then whateva user enter, he gets 'Incorect code from the image'.

When remove Proceed, from the action URI, and add everything become fine.

Hope helps

jbrown’s picture

I am also getting this problem.

I think there is a race condition, where the image writes the code in the session data, but then the page finishes after and sets the code back to the previous value.

Success’s picture

I'm facing this too.

jbrown’s picture

Assigned: Unassigned » jbrown

i fixed this problem by putting another field in the sessions table called captcha code and modified the captcha module to use this instead o a session variable.

However I think the best solution is to modify session.inc as follows

put

db_query("
SELECT GET_LOCK('mysite-%s', 60)
",
$key
);

at the top of sess_read

and put

db_query("
SELECT RELEASE_LOCK('mysite-%s')
",
$key
);

just before the return in sess_lock

this fixed a separate problem with drupal_get_messages not clearing the messages

do you use innodb??
which version of drupal are you running?

jbrown’s picture

sorry - thats sess_write, not sess_lock

ardas’s picture

It seems to me that patching Drupal core to fix issue in Captcha is a wrong way.

jbrown’s picture

The bug is in drupal's session handling. The built in php session handling does perform session locking, but drupal's custom db code does not. This should be fixed.

Veggieryan’s picture

whoa whoa whoa...

what????

has this bug not been fixed?
should we cross post this to the drupal core bug list???

IMPORTANT!!!!!!!!!!!!!!!!

robserious’s picture

Hi Guys,

I am running 4.7 and have experienced this bug. I have tried the session locking fix in sessions.inc which has worked.

I agree with Ardas and Veggieryan that this should be official, does anybody know if this bug was listed and if theres a patch or somethin out?

Cheers

soxofaan’s picture

Status: Active » Closed (fixed)

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.
  • The issue is not applicable to the now recommended 5.x-3.x and 6.x-1.x branches.