php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #20619 session data is lost
Submitted: 2002-11-25 08:02 UTC Modified: 2002-11-25 17:47 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: duh at dowebwedo dot com Assigned:
Status: Not a bug Package: Session related
PHP Version: 4.2.3 OS: Slackware 8.0.0
Private report: No CVE-ID: None
 [2002-11-25 08:02 UTC] duh at dowebwedo dot com
We also noticed the same behaviour on our development GNU/LINUX Debian 3.0r0 server. Both (dev) Debian and the (live) Slackware servers run Apache 1.3.26 with php 4.2.3 compiled as an apache shared module.

This is the configure command for both the debian and the slackware server:
'./configure' '--with-pgsql' '--with-apxs=/www1/bin/apxs' '--with-gd=/usr' '--with-png-dir' '--with-freetype-dir' '--with-pear' '--with-zlib-dir' '--enable-track-vars' '--enable-trans-sid' '--disable-posix-threads' '--enable-shared'

And part of our virtual host configuration (on both servers):
php_value session.cookie_lifetime 0
php_value session.name "SITE1"
php_value session.auto_start 1
php_value register_globals 0

The problem that we have seen on both servers (which didn't happen on earlier php versions) was that session data was lost. This occurs if you leave your browser open for a certain period of time (minutes). This should not happen since the session lifetime is set to 0 (session expires whenever the browser is closed). We also tried to increase the session lifetime to some days and even a year but still the problem is persistent. Also, on the servers it looks like the session file is still present containing the data you would expect it to contain, however the client browsing the site seems to have lost all session data. This seems odd because the cookie set in the browser show an infinite lifetime. We read and write session variables using the $_SESSION hash

On the same slackware server we run a second apache daemon (1.3.22) with php 4.1.2 (static) for an older website and here we do not see these session problems. The configure string for this php version is
'./configure' '--with-mysql' '--with-apache=../apache_1.3.22' '--enable-track-vars' '--enable-trans-sid' '--disable-posix-threads' '--with-gd=/usr/local' '--with-jpeg-dir=/usr/local' '--with-ttf=/usr/local/include/freetype2' '--enable-shared' '--enable-gd-imgstrttf' '--enable-versioning' '--enable-magic-quotes' '--with-unixODBC=/usr/local/easysoft/unixODBC/' '--with-png-dir=/usr' '--with-zlib-dir=/us'
On this older site we mainly use the $HTTP_SESSION_VARS global hash to read/write session variables as well as the standard php session_* functionality.

Maybe the problem is register_globals related? 

I hope someone can shed some light on this problem because we can't seem to find any solutions though we had some thorough digs in our code and configuration... 

Jeroen

Patches

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-11-25 08:42 UTC] duh at dowebwedo dot com
Hm, I tried to compile the latest CVS snapshot (php4-STABLE-200211251430) but it breaks on:

/root/download/php4-STABLE-200211251430/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp'

-Jeroen
 [2002-11-25 08:49 UTC] iliaa@php.net
That is a WARNING not an error, PHP was built correctly.
 [2002-11-25 17:47 UTC] sniper@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the original bug instead.

Thank you for your interest in PHP.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Aug 19 18:01:30 2024 UTC