Using Image Captcha on uc_checkout_form: $solution is always "undefined"

Can you try with CAPTCHA 6.x-2.3-rc1 (http://drupal.org/node/843974)?
And can you also experiment with the simple math CAPTCHA instead of the image CAPTCHA?

Each Form Submit inserts 4 Inserts in db table captcha_sessions

4 inserts with a different (successive) csid (CAPTCHA session ID)?

Is it only on the submit that you get 4 inserts?
Or is it two inserts when the form is rendered (before submit) and another two when you submit it?
In any case: how it should be: only one insert when the form with CAPTCHA is rendered initially and only updates on the same record during further processing of the form (validation, re-rendering, submit).

(changing to "support request" because this is probably ubercart doing weird non-traditional form stuff instead of a bug in the CAPTCHA module)

I am getting this problem - "The answer you entered for the CAPTCHA was not correct." - but it was correct - with the current version 6.2.3 - after updgrading on the 12/11/2010 - two days after its release.
Reverting back to 6.2.3-rc2 resolved the problem for me.

So, there might be something wrong in 6.2.3.

Just noticed this one 2 or 3 days ago. Looking into it, I got 3 different forms with the problem. Nothing to do with Übercart from what I can tell.

select csid, uid, form_id, solution, status, attempts from captcha_sessions where solution not in ('', '1') order by timestamp;
  csid  | uid |         form_id         | solution  | status | attempts 
--------+-----+-------------------------+-----------+--------+----------
 474731 |   0 | contact_mail_page       | undefined |      1 |        1
 485078 |   0 | contact_mail_page       | undefined |      1 |        1
 486393 |   0 | comment_form            | undefined |      0 |        0
 486399 |   0 | webform_client_form_482 | undefined |      0 |        0
 492991 |   0 | contact_mail_page       | undefined |      1 |        1
 501709 |   0 | contact_mail_page       | undefined |      1 |        1
 504189 |   0 | contact_mail_page       | undefined |      1 |        1
 518525 |   0 | contact_mail_page       | undefined |      1 |        1
(8 rows)

Looking at the code, if a session doesn't exist yet, it will be created and the solution set to 'undefined' by default. Then the code expects Drupal Core to call captcha_pre_render_process() which will save the solution in the table--solution that was defined in another function: captcha_process().

Why not save the solution in captcah_process() ? Is there a reason not to do so?

In the pre-render function you test whether the user is a valid CAPTCHA user (i.e. not skipping), the test goes like this:

if (_captcha_required_for_user($captcha_sid, $form_id) || $element['#captcha_admin_mode']) {

Right now I put a hack in my code so I'm fine, but it's really bad! 8-}

Thank you.
Alexis Wilke

P.S. 2 other details:

1. I use yet another CAPTCHA (i.e. the Hidden CAPTCHA). This shows it is not specific to the CAPTCHA in use...
2. Also it "rarely" happens. Most of the time it works as expected. I have no clue how to repeat the problem on my end.

There are some entries from another website. The strange thing is that it only fails for this IP address. All the others do get the CAPTCHA properly defined. A real fix would be useful here! 8-)

 csid  | ip_address  |        form_id        | solution  | attempts 
-------+-------------+-----------------------+-----------+----------
 14923 | 213.5.71.12 | testimonial_node_form | undefined |        1
 14925 | 213.5.71.12 | testimonial_node_form | undefined |        1
 14927 | 213.5.71.12 | testimonial_node_form | undefined |        1
 14929 | 213.5.71.12 | testimonial_node_form | undefined |        1
 14939 | 213.5.71.12 | testimonial_node_form | undefined |        1
 14941 | 213.5.71.12 | testimonial_node_form | undefined |        1
 14957 | 213.5.71.12 | testimonial_node_form | undefined |        1
 14962 | 213.5.71.12 | testimonial_node_form | undefined |        1

Thank you.
Alexis Wilke

Looking at the code, if a session doesn't exist yet, it will be created and the solution set to 'undefined' by default. Then the code expects Drupal Core to call captcha_pre_render_process() which will save the solution in the table--solution that was defined in another function: captcha_process().

Why not save the solution in captcah_process() ? Is there a reason not to do so?

I agree this might seem strange, but it is because of the way form building/submitting/validating in Drupal works.

To give a short overview (skipping some stuff, only showing the relevant parts):
- visitor goes to form with CAPTCHA
- form building: captcha_process creates new CAPTCHA session and challenge with answer AAAAA
- form is rendered: captcha_prerender_process stores answer AAAAA in database
- visitor receives form, fills it in (CAPTCHA response: aaaaaa) and submits
- form building: captcha_process is run, creating a new challenge with answer BBBBB
- validation: check if AAAAA (from database) == aaaaa (from visitor) and react appropriately
- if response was false: rerender form with challenge BBBBB

If the solution would be stored in captcha_process, we would have this:
- visitor goes to form with CAPTCHA
- captcha_process creates new CAPTCHA session and stores answer AAAAA
- visitor receives form, fills it in (CAPTCHA response: aaaaaa) and submits
- captcha_process creates new CAPTCHA session and stores answer BBBBB
- validation: check if BBBBB (from database) == aaaaa (from visitor) and react appropriately
- always fail: unhappy users :(

The point is that that form build functions like captcha_process come before validation.
So if we would write the solution to the database in captcha_process, we would overwrite the expected solution of the challenge the visitor responded to with the solution of a new challenge before we get the change to validate it original challenge. The visitor would never be able to pass the CAPTCHA (unless they could guess the solution for the challenge of the next form in the future).

The prerender phase comes after validation phase, so that is the place to store the solution of the (next) challenge)

Hope this makes it a bit clear.

soxofan,

Crystal clear! 8-)

Okay... Hmmm... So the question now is, why would Drupal not pre-render in some circumstances (or could the test in the pre-render function somehow fail?) I'm 100% sure that the last list of 'undefined' I provided were scammers automatically sending filled in forms (I saw the contents.) But the first person who posted about this issue had the problem trying their own website. So it would not just be because of a wrong request being sent to Drupal.

About #8, the problem started on Nov 21th around 4pm. I made no changes around that date (not that I know of that would in anyway interact with CAPTCHA.) Before that, the same IP address was being refused properly. This means I have a total of 175 requests by the same idiot. The first 167 there were refused as expected. Then it started showing 'undefined'. Could there be a limit in the number of SELECTed rows somewhere that when reaching 167 creates a problem?

One other thing, the following code is not multi-process safe, as far as I know. (I know everyone uses the same mechanism, but with PostgreSQL, the db_last_insert_id() is a SELECT from the sequence...)

  db_query("INSERT into {captcha_sessions} (uid, sid, ip_address, [...]");
  $captcha_sid = db_last_insert_id('captcha_sessions', 'csid');

But looking at the sessions, there isn't 2 hits occurring at the same time.

I checked a few other things like who's defined in the access table, and that IP is not in there.

The fact is that since I cannot myself reproduce the error, it's difficult to debug! (I guess you have the same problem... 8-) )

Thank you.
Alexis Wilke

I had the same thing happen to me when I had the user/register page open in a bunch of tabs.
Could that be causing it?

iamjon,

The 'undefined' was removed from CAPTCHA in the last 2.x-dev iteration. So you should not see that very problem anymore...

Thank you.
Alexis

thanks AlexisWilke,
I'll try it out. How production safe do you think it is?

There weren't very many changes, but there is one in the database so you have to run update.php. Just in case, you may want to have a database backup (if you think you may want to go back.)

That's the one I use and I have had no problems.

Thank you.
Alexis