CAPTCHA 5.x-3.x and earlier (but also e.g. 6.x-1.0-rc1) require sessions and consequently cookies to work.
With http://drupal.org/cvs?commit=101505 in HEAD (for Drupal 6) there is proof of concept that the cookie requirement can be dropped:
the storage of the challenge solutions in $_SESSION was replaced with a dedicated database table {captcha_challenges}.

This approach should probably be backported to the Drupal 5 version

Other advantages of the dedicated table:
* easier cleanup of old, unsolved challenges, now done in a cron hook (related to http://drupal.org/node/213928)
* the problem with CAPTCHA persistence (e.g. http://drupal.org/node/116050) should be easier to solve

Comments

soxofaan’s picture

soxofaan commented
Title: Drop cookie dependency » replace $_SESSION usage for CAPTCHA solution storage with dedicated table

I observed another issue with the usage of $_SESSION as storage and the image CAPTCHA.

For starters: the image CAPTCHA works with two requests: one for the normal drupal page (e.g. ?q=comment/reply/123), which stores the solution in $_SESSION and another one for the image itself (e.g. ?q=image_captcha/1828213109), which fetches the solution from $_SESSION.

In certain situations (e.g. I get it quite often on my localhost setup), it can happen that the request of the image starts before the handling of the request of the normal page has finished. Translated to $_SESSION usage, this means that the fetching of the solution happens before the storing, which obviously doesn't work.

I observed this behavior (sometimes the image shows up, sometimes it doesn't) already for a long time, but couldn't isolate the cause because of its random behavior, until now.

This is another reason to replace the usage of $_SESSION with storage that doesn't have the timing issue like a dedicated table.

yang_yi_cn’s picture

yang_yi_cn commented

I've downloaded the CVS-2008-08-21 version and still not sure if the $_SESSION has been removed, I still see a lot $_SESSION variables in the code, how can I test it ?

soxofaan’s picture

soxofaan commented

did you download it from http://drupal.org/node/94922 or did you got it through CVS?

There are indeed some $_SESSIONS's left in the base CAPTCHA module, now only used for persistence checking. I'm not sure if those should also be removed, as they are not really critical for the good working of the mode.

The removal of $_SESSION is not completed yet for the image CAPTCHA submodule, I'm still workin on it.

yang_yi_cn’s picture

yang_yi_cn commented

Thanks for your reply.

I was using the CVS directly.

However, I've located the root cause of my problem is the sess_write() function in sessions.inc is not good and causing race conditions.
as described in http://drupal.org/node/213699

The bugs doesn't appear very often when you have a clear Drupal installation. But as the ImageCaptcha put a lot more sessions to the sessions table and make the race condition easier to happen, the worse thing is, I have distributed the traffic to be load balanced between two servers and they replicates to each other. So in my situation it's much easier to duplicate the problem.

I've sovled the problem by patching the session.inc using "INSERT ... UPDATE ON DUPLICATED ID ..." syntax and my site is saved. But the SQL command is only avaiable to MySQL and will not be accepted to core, as http://drupal.org/node/213699 mentioned. Drupal 7 will use MERGE and solve it.

Talking about Captcha or ImageCaptcha, I think it's generally good idea to do less sess_write() as it can cause race condition.

Thank you anyway.

freeman-1’s picture

freeman-1 commented

soxofaan,

I encountered similar issues where the image fails to appear. Have checked the other issues opened here and none address/resolve my problem. I believe the problem probably lies with SESSIONS - possibly occurring more for browsers that pre-fetch the images or slower servers.

In my case, the Image Captcha (6.x-1.0-rc2 and dev) works on FF3 locally and remotely, as well as IE7 locally. But it consistently fails on IE7 when I upload my site to the remote (live) server - this is the opposite of your case.

So it seems the issue is one of synchronicity between requests for the main page and the image. I wonder if there are other related factors like the Apache/webserver settings that specifically causes this problem, or ISP transparent cache behaviors ? But in any case, most site developers don't have control over ISP caches and webserver settings for shared hosting.

Hope your task here resolves this problem.

soxofaan’s picture

soxofaan commented
Status: Active » Fixed

the 6.x-2.x branch is getting fairly stable now, so this issue can be marked fixed

Status: Fixed » Closed (fixed)

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