i've been tracking this down to:

if you try to read a value from the session that is not stored there (sess_write()) you will get logged out.

demo:
// log in as a user, then in a module do:
sess_read(time());
// call that page,
// reload page .. now you should be logged out.

F

Comments

ajessup’s picture

We've noticed this too on a 5.1.7 codebase.

damien tournoud’s picture

Status: Active » Closed (won't fix)

I don't see any bug in this. sess_read() is a private core function, that you should not call directly.

avpaderno’s picture

Status: Closed (won't fix) » Active

If it's private then it should be renamed to _sess_read(); at least it would be obvious it's a private function.

damien tournoud’s picture

Status: Active » Closed (won't fix)

Already done in D7.

avpaderno’s picture

The report is for Drupal 5.

damien tournoud’s picture

Drupal 5 and 6 are API frozen.

eric at nrd’s picture

I was bitten by this behavior in D6. It isn't immediately obvious that using sess_write() and sess_read() inside a module are incorrect (changing them to _sess_write() and _sess_read() in D7 sounds like a good plan).

If you need to read or write to the session, I believe that in D6 the preferred method is to use the $_SESSION[] superglobal variable as follows:

function module_setsessionvar() {
  // Write to the session
  $_SESSION['module_sessionvar'] = 'example value';
}

function module_getsessionvar() {
  // Read from the session
  $sessionvar = $_SESSION['module_sessionvar'];
}
smith2008’s picture

Version: 5.1 » 6.12
Assigned: Unassigned » smith2008

Yeah private should be PRIVATE. Supper global should be wrapped in something, so we can say this is the drupal api functionality.

damien tournoud’s picture

Version: 6.12 » 5.1
Assigned: smith2008 » Unassigned

There is nothing to do here. Those functions are already marked as private in Drupal 7. Drupal 5 and 6 are API frozen so nothing can be done there. The super-globals are a standard PHP feature, can and should be used directly.