php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15909 mysql and header() problem prevent saving session vars(?)
Submitted: 2002-03-06 13:11 UTC Modified: 2002-05-30 00:00 UTC
Votes:28
Avg. Score:4.8 ± 0.6
Reproduced:27 of 27 (100.0%)
Same Version:21 (77.8%)
Same OS:13 (48.1%)
From: phpbug at ehrlichorg dot com Assigned:
Status: No Feedback Package: Session related
PHP Version: 4.1.1 OS: Linux (Debian)
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2002-03-06 13:11 UTC] phpbug at ehrlichorg dot com
Several pages that worked in PHP 4.0.2 no longer work in 4.1.2. The problem is that values added to a global session variable array just before jumping to another page are not being stored.

For example, on page courses.php the user selects a course from a list. The code for the course is stored in a session variable $S[event_code], and the code pagejumps (by calling a library routine that calls header()) to page course.php, to display data for that particular course. The problem is, the value $S[event_code] no longer exists when we get to the second page (course.php).

I can see the value in $S[event_code] if I var_dump($S)  before the pagejump in courses.php. If I var_dump($S) just after arriving in page course.php, I see the other contents of the $S array but not $S[event_code].

Array $S is global and each page begins with
session_register("S");
The update takes place within a function that declares $S as global.

If I replace
$S[event_code] = $event_code;
with
$_SESSION[S][event_code] = $event_code; 
the value is passed.

PHP options enable_track_vars and register_globals are ON, session.save_handler is files, session.serialize_handler is php.

Thank you.



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-03-06 14:38 UTC] nospam dot ricko at garagegames dot com
Just wanted to confirm I also experienced this problem after upgrading to 4.1.2 for the security fix, so it's not an option to go back to an older version of PHP.

The suggested $_SESSION[S][X] work around fixed my shopping cart but this is going to be a huge chore to fix the entire site. 

Is there an ETA on this fix?
 [2002-03-06 14:56 UTC] phpbug at ehrlichorg dot com
Re: nospam.ricko@garagegames.com 
FYI, The code I'm working with uses a single session array variable (with many elements) and a library routine to do page jumps. Consequently I was able to fix this problem on all my pages by adding one line of code to the pagejump library routine.
 [2002-03-08 15:06 UTC] baatsaam at hotmail dot com
I experienced a similar problem (PHP 4.1.2, Linux 2.2.19-6.2.11)

Works:
onepage.php
-----------
session_register("newvar");
$newvar = 123;
header("Location: somepage.php");

somepage.php
------------
echo $_SESSION["newvar"]; //echoes 123

Doesn't work:
onepage.php
-----------
$_SESSION["newvar"] = 123;
header("Location: somepage.php");

somepage.php
------------
echo $_SESSION["newvar"]; //"newvar" isn't set here
 [2002-03-09 22:37 UTC] baatsaam at hotmail dot com
According to the session docs:
If you have register_globals On, you have to use session_register()
If you have register_globals Off, $_SESSION['var'] = 123 will register it

That means that you have to switch everything over to the $_ vars and turn off register_globals before sessions work correctly (because the $_REQUEST[], or user input, vars won't be available globally any more).

If I'm wrong, let me know :)
 [2002-03-14 10:14 UTC] jake at sunburygroup dot com
Any attempt I have made to save session variables in 4.1.2 fails now.  I can replace my php version with 4.1.1 and it works fine.  I have noticed that the session files are created in the temporary directory, but while they contain the encode session data in php 4.1.1, they are 0 byte files in php 4.1.2.  I am using IIS5.0 on Win2k.  This fails in both the CGI and ISAPI version.  I can reproduce it every time simply by stopping IIS, replacing php.exe, php4isapi.dll, php4ts.dll, and php4ts.lib, restarting IIS, and trying it.  No changes to code and no changes to php.ini.  Not even the php session manual's sample for showing the number of times you have visited a page works!!  I really want this security fix, but I can't upgrade to it if it's going to break sessions.

I do run a "slightly" (not where it really counts) modified php.ini that resembles the php.ini-recommended in almost every respect.

I think this a glaringly obvious bug and can't imagine it can't be reproduced, just try the sample - I have confirmed and reproduced this bug on THREE IIS5.0 Win2k platforms.
 [2002-03-18 11:19 UTC] phpbug at ehrlichorg dot com
Here is part of what is going wrong. PHP starts out with each session variable appearing as a global and also in $_SESSION. Initially these are linked by reference (not clear how) and contain the same data. On my pages this linkage appears to get broken so the contents $GLOBALS['S']
and $_SESSION['S'] are not the same. $GLOBALS contains the latest data, $_SESSION contains the data as of the start of the page. Consequently changes to the $_SESSION variable are not being saved between pages.

My work around is to use the following at the end of each page for $S:

	if ( !($_SESSION['S'] === $S) )
		$_SESSION['S'] = $S;

This updates the contents of the $_SESSION variable if it is not longer the same as the global.

Based on a comment from one of the developers, the problem may relate to having a global declaration for a session variable that appears outside a function scope. I have these declarations on each of my pages because PHP used to require them.
 [2002-03-20 06:07 UTC] johnsparrowuk at yahoo dot com
Interesting workaround:

session_register("lastaction");
session_register("userip");
session_register("lines"); // etc etc
$HTTP_SESSION_VARS["xx"] = "Anything"; // this is the magic bit

Although xx isn't a registered session var, and doesn't get stored in the session, it seems to stimulate PHP to update the session vars in the file!

With that addition, my apps now work fine under 4.1.2.. (Win 2k, Apache 1.3.23)

John
 [2002-03-25 03:18 UTC] irenem at ms2 dot hinet dot net
It looks like the PHP 4.1.2 forgot to call session_write_close() by default. I added this call at the end of my program, and solved this session problem.
 [2002-03-25 05:09 UTC] yohgaki@php.net
Hmm. It sounds like PHP is segfaulting. (Or bailing out without proper shutdown)
If you are having segfualts, could you build PHP with --enable-debug and send the backtrace?



 [2002-03-25 21:15 UTC] phpbug at ehrlichorg dot com
PHP Does not appear to be seg faulting; nothing in the logs indicates that type of error.
 [2002-03-26 00:40 UTC] yohgaki@php.net
Do you use MySQL?

 [2002-03-26 11:55 UTC] phpbug at ehrlichorg dot com
Yes, we are using MySQL 3.23.38 in the application. However, the session.save_handler is files. 

We were using the same version of MySQL with PHP 4.0.2.
 [2002-03-26 21:44 UTC] yohgaki@php.net
Could you limit size of max text size returned from MySQL?
Does it help?
 [2002-03-27 12:02 UTC] phpbug at ehrlichorg dot com
Sorry, I don't see where I would limit size of max text size returned from MySQL or what you are looking for. Please clarify.

The applications that are not working are not using large text fields. Most are defined as TINYTEXT and TEXT. There are a couole of columns defined as MEDIUMTEXT (due to misunderstanding of field types) but the contents are less than 4000 bytes.
 [2002-03-28 19:12 UTC] yohgaki@php.net
There is bug report for MySQL.
After serval database operation, calling heade() crashes PHP for some reason according to the bug report.

Anyway, I don't use MySQL and I don't have this problem.
We need backtrace or need where/how PHP is bailing out.

Build with --enable-debug and check what is going to with debugger.


 [2002-04-29 00:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2002-04-29 12:21 UTC] phpbug at ehrlichorg dot com
MySQL is not the problem. We have not changed MySQL versions, just the PHP version. 

Some of the cases that fail do not do any database operations. They change a context variable and page jump (via header()) to another PHP page.

If this were a MySQL problem, the work around I described above would not fix it.

The problem appears to be with PHP and the management of session variables.

Note: Status should be changed to Open but the only options I have are No Feedback or Closed.
 [2002-04-29 15:23 UTC] sniper@php.net
Does this happen with latest CVS (stable branch) snapshot ?

http://snaps.php.net/php4-STABLE-latest.tar.gz

--Jani

 [2002-05-30 00:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2006-07-07 00:44 UTC] jallinson at optusnet dot com dot au
using session_write_close(); after seeting the session variable solved it for me.
 [2007-11-06 09:56 UTC] kapilgopinath at gmail dot com
NBMNMNBMBNMBN
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 08:01:27 2024 UTC