session_id is not available for anonymous sessions

I installed content_profile and content_profile_registration modules and I'm not able to replicate this issue. Registering new users works just fine.

I got a call from a user today who complained that she couldn't create an account on our dog run site because the "CAPTCHA thing" wouldn't let her in.

I tested it out and she was right. No matter what I entered at the New User Creation form I kept getting the error "The CAPTCHA was not completed correctly. Please complete this new CAPTCHA and try again."

It didn't matter whether a visual or audio CAPTCHA was presented. It worked fine until I updated to mollom-6.x-1.12 on March 5. I tested this problem in both FF and Safari.

I also have an extended user profile form.

Added: I rolled back to the second most recent Mollum tarball I have here (6.10) and there are no problems with user registration.

I have exactly the same problem on all pages (user registration, contact form) which use Mollom on a site which has worked without problems until a day or two ago. I upgraded to the latest version of the core 6.16 a few days ago, so I guess it may be related. I've tried completely uninstalling and reinstalling Mollom but no joy :(

@dobe: wow, thanks for making sure that you also cannot replicate it on a clean install! That is really a giant help for debugging this issue. Thank you! :)

Given this important detail, I can only think of

1) any custom hook_form_alter() implementations?

2) hook_form_alter() implementations in some of the installed modules that may be configured differently; anything that interacts with forms is questionable - therefore:

Automatic Nodetitles
Content Profile
Form Markup
Override Node Options
Unique field (not sure)

Would it be possible to copy your production site's database to a local development copy and disable those modules (step by step)? (Note that http://drupal.org/project/demo might be helpful for that)

Having the same issue. Following.

I have this issue too; running drupal core 6.16, and also have an extended user registration page. Installed mollom-6.x-1.10 insead of .12 and now all is working, so I guess this avoids the issue for now for me, but I would like to be able to use the .12 releases feature of being able to process arbitrary forms.

@dobe: Any news?

subscribe

I debugged this in the Mollom backend using the cuiltext.org website. When trying to create an account, the image captcha is correctly requested by the website, and fetched by the user, but when the captcha is filled in, I get this error in the backend:

[Fri Mar 12 21:13:15] [http://cuiltext.org] called 'mollom.checkCaptcha'
[Fri Mar 12 21:13:15] [http://cuiltext.org] called checkCaptcha with no session ID, returning false

This shows that the Mollom module does not pass a session ID when trying to test the captcha response. This is a module issue. It is probably not due to caching, but the registration form has extra fields, so possibly an issue with the profile or users as nodes integration.

User just contacted me today with this issue.

We are still on Drupal 6.15. Was planning to update this weekend.
I have not updated or changed any modules since we had our last registrations.
And I know we've had registrations which have passed the CAPTCHA test since updating the mollom module to 6.x-1.12.

Could this be some change in API / error on mollom's end?

I am having the same problem hope that this gets solved soon.

As it seems all of you have this issue after updating to the latest version - is it possible that not only the user registration form is protected by Mollom, but also the node form that is used by Content Profile?

I think I've tried every possible combination of configuration options now. Still no luck - I'm unable to replicate this bug.

However: Which PHP version are you on?

Also, how about php.ini settings for error_reporting and display_errors ?

- Tested with CCK and additional fields, and without.

- Tested with Content Profile + Content Profile Registration and without.

- Tested with latest official releases, development snapshots, and all possible combinations of both Content Profile and Mollom.

- Tested with additional protection of Profile node type form and without.

- Tested with administrative approval of new user accounts and without.

- Tested with Mollom testing keys and real keys.

- Analyzed and scanned Content Profile module's code for any possible harmful code.

I'm running out of ideas, and I need more info.

Thus, if you experience this bug on your site, please compare the list of installed modules mentioned by @dobe in #7.

Any additional information you can provide, please state it.

Additionally installed + configured the modules:

- Automatic Nodetitles
- Form Markup
- Override Node Options
- Token
- Unique field

Still works like it should.

I can confirm everything except that #22.

The session_id was not getting sent in the XMLRPC request to mollom.com when the user submitted the user/register form, even though it was submitted in the POST to my site (in the POST data, the session_id includes a timestamp prefix as well).

I did not have Content Profile installed and I did have a correct user 0 (Anonymous). I did have Login Toboggan and Persistent Login enabled but they were not affecting it.

The problem for me was due to no Anonymous sessions, introduced by http://drupal.org/project/no_anon causing anonymous users to have nothing in $_SESSION. It says quite clearly in the README.txt and the project page for that module:

Side effects
------------
Some modules use the $_SESSION superglobal variable to store info for anonymous users
will be affected by this module. If your modules use this only for logged in users,
then it will not be an issue. Before you install this module, make sure that your modules
do not depend on that.

/**
 * Form element #process callback for Mollom's form storage handling.
 *
 * Albeit this *should* be an #element_validate handler that is only executed
 * during form validation, we must use a #process callback, because
 * mollom_process_mollom() needs to copy over $form_state['mollom'] into
 * $element['#mollom'], and as of now, Form API does not allow form validation
 * handlers to alter any elements in the form structure by reference.
 * @see http://drupal.org/node/642702
 */
function mollom_process_mollom_session_id($element, $input, &$form_state) {
  // The current state can come either from the $form_state, if the form
  // was just rebuilt in the same request or from data posted by the user. In
  // that case we validate that the correct form_id and user session ID is used.
  if (empty($form_state['mollom']) && !empty($input['session_id'])) {
    @list($timestamp, $mollom_session_id) = explode('-', $input['session_id'], 2);

    if (empty($mollom_session_id)) {
      watchdog('mollom', 'Bogus session id %session.', array('%session' => $form_state['input']['mollom']['session_id']), WATCHDOG_WARNING);
    }
    elseif (!isset($_SESSION['mollom_sessions'][$mollom_session_id])) {
      watchdog('mollom', 'Non-existent session id %session.', array('%session' => $mollom_session_id));
    }
...
  return $element;
}

In my site's settings.php, I had this:

/**
 * Disable anonymous sessions with no_anon module
 */
$conf['session_inc'] = './sites/all/modules/no_anon/session-no-anon.inc';

After commenting that out, it works properly again.

I noticed some comments in HEAD about forcing a session for anonymous users in D7 and Pressflow 6.x. Are other people who experience this problem using Pressflow by any chance, or like me and neglected to check for problems when installing no_anon?

See also:
http://drupal.org/node/353428
http://drupal.org/node/315830

I don't believe this is a bug in mollom so I'm setting it back to support request.

So far there are 2 possible causes:

1. You do not have a user with uid=0 (no Anonymous user)
2. You have disabled anonymous sessions

Just want to clarify something..

This started happening on our site when we were on Drupal 6.15 and Mollom version 6.x-1.12.

Updating to the latest version of Drupal saw no change.

We do have user 0, and we do allow anonymous sessions.
We are not using any modules like no_anon etc.

So I have to say I don't see the fix / cause of this problem being the same as is being said above.

@dobe, Mollom actually logs things in the watchdog.

@scratt - let's see if we can work it out then while it's fresh in my mind. Can you do any or all of these in this order?

1. Check your log (admin/reports/dblog) and filter for Type=mollom. Do you see 2 log entries at the same time, like this?:

   1. Incorrect CAPTCHA:
      
      Array
      (
          [name] => user@gmail.com
          [op] => Create new account
          [submit] => Create new account
          [form_build_id] => form-865462eaa134f78595999ef05d9fd99c
          [form_id] => user_register
          [mollom] => Array
              (
                  [session_id] => 1269688832-100327c652a98bb96f
                  [captcha] => Npf2d
              )
      ...
      

   2. Non-existent session id 100327c652a98bb96f.

   That last one is the session_id that should be sent to mollom.com in the XMLRPC request.

2. Clear your cache and test again.
3. Check that your browser has cookies enabled.
4. Verify that you are not behind a firewall or proxy and that other XMLRPC requests work such as the core Ping module or contrib modules like Location, OAuth or Pingback.
5. On a development server:
   1. Install and enable the Devel module and check 'Collect query log' and 'Display query log'. Also set the permission 'access devel information' for Anonymous users (access to user/register is denied for authenticated users and you won't see the query log otherwise). That will produce quite a long page but you should see about 10 database queries if you search for mollom. Are logs being written using the watchdog() function?
   2. Run the same SQL queries manually to see what is in the tables.
   3. Snoop the network traffic going to mollom.com using tcpdump if possible. Eg.# tcpdump -s 1500 -w /tmp/mollom.dump mollom.com
   4. Copy /tmp/mollom.dump to your desktop and load it with Wireshark. Find a packet of XML/RPC type, right click and choose 'Follow TCP session'. Do you see the session_id being sent?

After all that, if you still don't find the problem or session_id is being sent to mollom.com, then your problem is different to the original poster.

@dobe - You should see if migrating your site again will drop your uid=0. Maybe there is a previously unnoticed bug in Content Profiles.

@wad Thanks for your feedback.

1. Tried that with various test users. Got the following :

Incorrect CAPTCHA:
Array
(
    [name] => testUser
    [mail] => xxxx@xxxxxx.xxx <- My EDIT.
    [timezone] => 25200
    [op] => Create new account
    [submit] => Create new account
    [form_build_id] => form-db9ac83b9b680100b714935d3338daec
    [form_id] => user_register
    [chimpmail_list_f73be52f99] => 1
    [mollom] => Array
        (
            [session_id] => 1270100273-100401d8c77d5a0931
            [captcha] => Msv4m
        )

)

Non-existent session id 100401d8c77d5a0931.

2. Cleared Cache. Same results.
3. Cookies are enabled.

Bear in mind I was informed of this problem initially by various people trying to register for the site starting on one specific day. Prior to that we had had no issues, and no updates had been done on the site between getting successful registrations and then this problem occurring. Which is just bizarre.

Since then I have reinstalled Mollom, restarted the server various times, updated Drupal, and cleared the cache more than once. Both on the server and also in Drupal.

4. Nope.

5. I will take some time out to do this in the coming days.

FWIW, although I have not carried out your specific tests yet, I can confirm that both this site, and the other two sites on this same server, all regularly communicate with other services provided by companies similar to Mollom without any problems. It's a dedicated server which we have complete control over.

Would appreciate some feedback on what I have posted so far though.

Thanks

@scratt - Check your php.ini and settings.php for any resetting of sessions. This is what I have:

$ grep ^session /etc/php5/cgi/php.ini
session.save_handler = files
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.serialize_handler = php
session.gc_divisor     = 100
session.gc_maxlifetime = 1440
session.bug_compat_42 = 1
session.bug_compat_warn = 1
session.referer_check =
session.entropy_length = 0
session.entropy_file =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 0
session.hash_bits_per_character = 4
$ grep ini_set..session /path/to/site/sites/default/settings.php
ini_set('session.cache_expire',     200000);
ini_set('session.cache_limiter',    'none');
ini_set('session.gc_maxlifetime',   200000);
ini_set('session.save_handler',     'user');
ini_set('session.use_only_cookies', 1);

Perhaps someone else can comment on whether that is optimal for using mollom as I have no idea, it just works.

You should easily be able to capture the packets with tcpdump on a dedicated server. Do you see the mollom session_id being sent in the XMLRPC request?

You mentioned you have success with other services but are they calling xmlrpc() to achieve that?

I have similar php settings to you, but not identical :

session.save_handler = files
session.save_path = xxxxxxxxxxxxxxxxxx <- My edit.
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor     = 1000
session.gc_maxlifetime = 1440
session.bug_compat_42 = 0
session.bug_compat_warn = 1
session.referer_check =
session.entropy_length = 0
session.entropy_file =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 0
session.hash_bits_per_character = 5

I am no expert here with what may or may not affect Mollom, so if you see anything that is worth changing I would appreciate it.

Here is my settings.php

ini_set('session.cache_expire',     200000);
ini_set('session.cache_limiter',    'none');
ini_set('session.cookie_lifetime',  2000000);
ini_set('session.gc_maxlifetime',   200000);
ini_set('session.save_handler',     'user');
ini_set('session.use_cookies',      1);
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid',    0);

I am doing the tcpdump stuff today and will post back.

xmlrpc seems to be working fine, and yes is used by other things...

However, in my dump, whilst I can see comms. with Mollom going on, I cannot see the specific session ID being sent.

I will do some more digging today, as I was not able to get tcpdump to work quite as elegantly as I hoped on the server. (I am not a tcpdump expert!)

Also the raw dump data I have I would rather not post here, but am happy to send to people.

The no_anon problem is covered by #775398: Disabled cookies == no session data, impossible to submit a protected form.

Any updates on this?

Hoping we may hear back from someone with regards to the info I posted above...

This issue persists with the latest version of Mollom, and a fully updated site with a complete database update.

Yes, I am using Drupal 6.16, the latest version of Mollom, cookies enabled, anonymous sessions allowed. No_anon module is NOT installed. But I'm unable to get past the CAPTCHA, as others have described.

http://drupal.org/node/750896#comment-2933688 - related to Facebook Connect?

I have nothing to do with Facebook on my site. :)

Yeah, I don't think it's directly the fault of the Facebook Connect module... but there may be a clue. Maybe the same thing that's causing FB Connect to conflict with Mollom is also causing some other module of yours to conflict with Mollom.

This may not help everyone or has been mentioned previously, but I was having this issue and noticed I didn't have an anonymous user in the users table.

Not sure why it had vanished, since it was there previously. However, I've added a new user into the DB (directly not through user management) and set the UID to 0 (after insert since it uses the auto increment initially).

This has fixed the no session_id issue for me and Mollom is working again.

Thanks,

Luke

Re. the missing anonymous user entry in {users} table, you may be seeing #204411: Anonymous user id breaks on MySQL export/import (xID of Zero get's auto-incremented on external xSQL events). Might be worth checking you don't now have 2 entries with empty name and password. Especially see http://drupal.org/node/204411#comment-1812126.

While all of this is not really caused by Mollom module, it seems like sufficient people think that everything is caused by Mollom.

To prevent bogus blames, I propose attached patch.

I'd probably prefer this added to hook_requirements().

well, the original variant of this code actually already runs when hook_requirements() runs: http://api.drupal.org/api/function/system_status/6

Yuck. That is one ugly bug to work around.

+++ mollom.info	2 Aug 2010 15:36:56 -0000
@@ -2,3 +2,7 @@
+; http://drupal.org/project/module_supports

I don't get this code comment.

+++ mollom.module	2 Aug 2010 15:45:42 -0000
@@ -1052,9 +1053,21 @@ function _mollom_status($reset = FALSE) 
+      db_query("UPDATE {users} SET uid = uid - uid WHERE name = '' AND pass = '' AND status = 0");

Any reason we can't do 'uid = 0' (instead of 'uid = uid - uid').

Personally, I don't think it is the Mollom module's job to try and fix one's database.

+++ mollom.info	2 Aug 2010 15:36:56 -0000
@@ -2,3 +2,7 @@
+; http://drupal.org/project/module_supports

...is Dave's nice little module, which should actually be in core already. We can prefix this comment with "Support for".

Any reason we can't do 'uid = 0' (instead of 'uid = uid - uid').

Drupal core does it that way. Most likely, there's a good reason for this very odd value assignment. I hope so, at least ;)
#204411: Anonymous user id breaks on MySQL export/import (xID of Zero get's auto-incremented on external xSQL events) should hold the details.

Personally, I don't think it is the Mollom module's job to try and fix one's database.

Me neither. But hey, we're at #45 here + not counting plenty of duplicate issues. :-|

I'm not sure if warning people about lack of user 0 is going to fix this issue - as I have a user 0 but still don't have access to a working Mollom.

Also, I don't use fbconnect. I will try to carry out #28 when I can to try and suss this out better.

Re-rolled with better comments.

I've removed the code duplication of system_status() and instead went with a simple link to the status reports page.

I'm still not convinced we want this cruft. Let's not commit this yet.

Me neither. This bug is clearly caused by a bogus MySQL import. I can only recommend to use http://drupal.org/project/demo or a similar tool to export and import a Drupal database.

Furthermore, the compatibility with no_anon module should already be resolved in 6.x-1.14.

In case any other issues are not yet resolved, please open separate + dedicated issues for them, so we are able to properly track each issue's individual status. Thanks all!