session_destroy() [<a href='function.session-destroy'>function.session-destroy</a>]: Trying to destroy uninitialized session in /pressflow-6.16.77/sites/d6.local/modules/tokenauth/tokenauth.module on line 250.

Look familiar? This is also discussed in #823992: pressflow compatibility.

Because this fails, if you log in to the site with tokenauth, you need to logout normally.

Comments

Grayside’s picture

Grayside commented

Seems related to:
#758730: Fatal error on logout
#834962: Fix session handling issue
https://bugs.launchpad.net/pressflow/+bug/513117
https://answers.launchpad.net/pressflow/+question/103955

Furthermore, in digging into this issue, it will also be a d7 compatibility problem.

hefox’s picture

hefox commented

Subscribe

My guess is is that it sets stuff to the $_SESSION variables but doesn't generate the session, ie. http://api.drupal.org/api/function/user_authenticate_finalize/6

Edit: nevermind, didn't realize hpow much pressflow effects those areas.

Grayside’s picture

Grayside commented

Thanks for the look. Latest 1.x-dev is currently using user_external_login() to trigger authentication specifically to cross all the T's of a correct session, but Pressflow does handle it differently.

hefox’s picture

hefox commented

So it's fixed in dev? Mark it as fixed then if it is.

For those using stable, can tell it to not write session data for pressflow via:

/**
 * Implementation of hook_init().
 */
function mymodule_init() {
  global $user;
  // Process any provided token and log in user
  if (!empty($_SESSION['tokenauth_auth'] )) {
    drupal_save_session(FALSE);
  }
}

In a module that runs after tokenauth

Grayside’s picture

Grayside commented

No, I have not got it working, else it would be marked as fixed. I have it working more completely in -dev, but there have been no changes that resolve this particular issue.

Have you found that change works? I will look into that approach.

hefox’s picture

hefox commented

These changes worked for stable, but I doubt they'll work for dev, but something akin to that likely will work; basically either don't write the session or destroy the session if it's been created.

Grayside’s picture

Grayside commented

Destroying the session seems to be the problem introduced by Pressflow--it doesn't work directly. There are a variety of hacks spinning around as Pressflow and D7 devs work out exactly how this should be gracefully handled, which is why I've linked to some issues without nailing down a specific approach.

I have no objection to rearranging -dev to prevent the creation of a session to begin with. I formalized the current approach in an effort to increase compatibility, which did not really achieve anything.

I can't quite think of a key scenario where a tokenauth-based login would need a session. If I'm missing something please post.

Grayside’s picture

Grayside commented
Status: Active » Fixed

http://drupal.org/cvs?commit=408690

Status: Fixed » Closed (fixed)

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