I found an old bug report at PHP :: Bug #14636 :: Session variables are lost when redirecting to a url using header() function. that describes a scenario in which the session data may be lost after a redirect, but the setup and solutions defined in the bug report don’t seem applicable to my situation.
In my case, I’m running into the same (or eerily similar) issue on a Apache/2.0.52 (Red Hat) server running PHP 4.3.9. The session name for this application (“users”) is set at the top of the main entry point script, from which all other scripts are included. A typical URL looks like “main.php?do=something”, where something_inc.php is a file that gets included inside main.php.
The session data “sticks” as usual until one particular page does a redirect in JavaScript using “window.location.href = ‘main.php?do=issue_remove_image&id=’+id+‘&file=’+file;” Main.php again sets the session name to the standard name, but the session info is blank according to issue_remove_image_inc.php. From that include file, I have confirmed that:
a.) the session name is indeed set by the time we get to that file;
b.) the session is empty;
c.) no other requests are being generated that might account for the missing session;
d.) no part of the process is explicitly destroying the session or messing with the session values in between the time the previous page is displayed and the time the redirect is handled.
This appears to have started recently as it is a new bug report. However, I can’t confirm that as it’s the first time I have worked on this site. According to the owners of the site, it worked before.
On my local MAMP server running PHP 5.2.13, the issue is not present.
Any ideas?
Something somewhere must be destroying the session.
If you were using AJAX, I’d be suggesting that there is a fault with the browser not passing the session ID but you’re not so its an odd sounding one.
Any chance you can post some code for us to look at?
That’s what I thought too, so I dropped a bunch of debug statements in every function that called a session_* function or modified either of the session keys (email and uid) that the application uses to determine if a user is logged in or not. Nothing that would affect the session like that get’s called during the request that the redirect triggers.
I just finished an exhaustive round of debugging and determined that it only happens on the production server, and only when the “file” parameter of the querystring ends in “.jpg” or “.png”. So, I’m guessing that there is some silly URL rewrite thing going on in some apache conf file (there is no htaccess file), which I don’t have access to. Or, there’s some function that’s doing using a regex to examine the REQUEST_URI server variable and not distinguishing the file extension from the extension in the querystring.
Looking through the code for something like that now.
EDIT: It’s worth noting that I’ve tried other ending the querystring with other extensions such as “.txt” and “.php” but they don’t trigger the error. Only the two mentioned above plus “.gif” (but not “.bmp”)…
So I can’t get in touch with anyone at the company at this hour, but I’m wondering if this is an Apache issue, a configuration issue, or a PHP issue. I was able to reproduce the issue in a new PHP file w/o any of the include files. If anyone has a copy of PHP 4.3.9 available, could you try uploading the following PHP code and then try accessing it a couple times with random querystring arguments, and then finally with an querystring that ends in “.jpg”
You should see the session variable “foo” increment each time until the final request when the session array should be empty.
<?php
error_reporting(E_ALL ^ E_NOTICE);
ini_set('display_errors','Off');
ini_set('log_errors','On');
ini_set('html_errors','Off');
ini_set('session.gc_maxlifetime', 3600);
session_name('users');
session_start();
function printvar($var, $label="") {
print "<pre style=\\"border: 1px solid #999; background-color: #f7f7f7; color: #000; overflow: auto; width: auto; text-align: left; padding: 1em;\\">" .
(
(
strlen(
trim($label)
)
) ? htmlentities($label)."\
===================\
" : ""
) .
htmlentities(print_r($var, TRUE)) . "</pre>";
}
printvar($_SESSION, 'SESSION');
$_SESSION['foo'] = @intval($_SESSION['foo']) + 1;
?>
EDIT: Here’s a list of the URLs that I tried. The ones marked with a * indicate where the session was reset.
Hang on, you’re telling me that this script also outputs images?
Have you used session_write_close() before the image output?
No, it just accepts an image name as one of the QS parameters.
Hmm… I remember vaguely having this in my own code once… I can’t remember what the problem was though which is annoying.
I do have a WAMP setup using php 4 on my system. I’ve got a couple of things to do now but I’ll give your code a playing-with later and see if I can reproduce the problem.
Thanks. No worries if you can’t get to it. Even if you do confirm it as a bug in PHP, it is unlikely that I will get the host to update their PHP installation, and I doubt the PHP consortium will care much about patching such an old and obscure release 
However, it would help to know that it isn’t a bug in PHP so I can go back to the client to try to get more info on what’s going on behind the scenes. Maybe they use a reverse proxy server for serving images and the regex that detects the request is bad.
You’re missing the point… If its a bug and I’ve suffered from it too I found a way around it somehow (takes me days/weeks sometimes but I get there).
I’ll see what I can do… otherwise we might end up having a desktop connection via TeamViewer so I can do more bug hunting…
Yes, of course. I just meant if it ends up being a bug in PHP. I have a couple work-arounds in mind already (it should really be a form post action anyway), but at this point I’m more curious to see if it’s a bug in PHP or with their LAMP architecture. That’s why I said “no worries” if you can’t get to it.
That will never happen since version 4 was declared totally dead a couple of years ago and all the security holes discovered in it since then are also unpatched and available for anyone to utilize. All sites were supposed to upgrade to version 5 about five or so years ago.
Just to follow up on this, we were able to trace the issue back to an instance of Varnish that our web host has installed. The default config for Varnish evaluates the URI as a whole (QS included) and was unsetting the session for certain types of binary files. We had to update the config to filter out the QS with a regex first.
Hi
Glad you got it sorted and I’m sorry I’ve not got back to you since my last post. I’ve had some rather nasty legal issues come my way which pretty much wiped the table clean of anything else I was dealing with.
Sorry for the delay but its good to hear you’ve fixed it.
