Incompatible with Pressflow

This is the problem here: #562374: Mollom incompatible with Pressflow's (and Drupal 7's) session handling -- causes CAPTCHAs to fail.

Note: Fixing this problem is necessary to upgrade this module to Drupal 7, too.

The code I currently have in place for 7.x simply adds a value to the session superglobal:

$_SESSION['session_api'] = TRUE;

and that seems to work. Will this fix work for Pressflow 6.x?

I think the main problem with Session API when using with Pressflow/Drupal 7 is the was Session API utilizes BOTH cookies and the PHP session. Statements like this:

if (!is_numeric($_SESSION['session_api_id'])) {

Will cause things to fail since $_SESSION isn't created immediately for all users like it was in Drupal 6. If we can avoid $_SESSION and just stick with $_COOKIE, we should be able to use Session API with things like Akamai and Varnish, right now they don't seem to work together.

On further investigation I don't think it's use of $_SESSION that's directly the problem, but the use of session_id(). From the php.net docs:

session_id() returns the session id for the current session or the empty string ("") if there is no current session (no current session id exists).

Since no session exists for users in Pressflow or Drupal 7, Session API gets thrown off. We could work around this by starting a session, but then all anonymous users have sessions again and we've lost the benefits of using Pressflow (since users with sessions are not cached by Varnish or Akamai).

This patch we're trying out on our environment, which strictly uses $_COOKIE and avoids any use of $_SESSION. User "session_ids" are generated by a combination of time(), ip_address(), and the private Drupal token, which should prevent any spoofing of session IDs.

Hi!

The above patch will get session_api to work with pressflow, but depending on how you use session_api, it could render any reverse proxy caching mechanism useless. I propose that we add a "create" parameter to session_api_get_sid that defaults to TRUE, so that the caller for session_api_get_sid can choose not to create a sid if the cookie isn't set by simply passing FALSE to the function. This will mean the following:

* The session_api_session cookie will not be set unless the caller wants it to be.
* Reverse proxy caching servers like varnish can be configured to let the backend serve the page if the session_api_session cookie is set, since that indicates that content shown only to that user should be served, and since it won't be set otherwise (if the calling modules are cleverly engineered) it can safely served cached pages if the cookie isn't set.
* Session API will still work as intended without any API changes for implementing modules, but they can choose to be reverse proxy caching-friendly.

Here's a patch that takes this approach. I also updated the tests so that they work with cookies instead of sessions.

Thanks fabsor, I've found that my approach does not work as you've noted. I'll give yours a shot when I get a chance.

Thanks fabsor, I like this approach. I'm in the process of trying to get additional eyes on this patch to make sure it doesn't break existing implementations.

Subscribe.

subscribe, same problem

I've been testing this on a current project with domain_user_default, and it is working as expected. Committed to dev.

Ported to 7.x.

I'm still having an issue with the flag module with sessions api running on pressflow 6 (IE6 user doesn't have permission bug when they flag). It works well on a vanilla Drupal install.

Just to be clear was the patch included in the latest 6 dev sessions api as well?

FYI - The patches committed for this issue have introduced a bug - #1140064: Cron hook incorrectly deletes all session api records.

@MBug - patch is included in 6.x-dev and releases 6.x-1.3 onwards.