Posted by fjen on April 27, 2007 at 8:01am
Jump to:
| Project: | Drupal core |
| Version: | 5.1 |
| Component: | user system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
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
#1
We've noticed this too on a 5.1.7 codebase.
#2
I don't see any bug in this. sess_read() is a private core function, that you should not call directly.
#3
If it's private then it should be renamed to
_sess_read(); at least it would be obvious it's a private function.#4
Already done in D7.
#5
The report is for Drupal 5.
#6
Drupal 5 and 6 are API frozen.
#7
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:
<?php
function module_setsessionvar() {
// Write to the session
$_SESSION['module_sessionvar'] = 'example value';
}
function module_getsessionvar() {
// Read from the session
$sessionvar = $_SESSION['module_sessionvar'];
}
?>
#8
Yeah private should be PRIVATE. Supper global should be wrapped in something, so we can say this is the drupal api functionality.
#9
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.