Session handling problem - sessions are lost

sessions getting lost, php, apache, IE

[unipus]

Sorry, I no longer really know where to post this problem. It might be a PHP problem, it might be a server configuration error, it might be an IE bug... I dunno. Please read this despite the length...

Basically, sessions are getting "lost" for a small percentage of users (varies; 1 to 5 percent, I estimate). Some tracking has shown that the server is giving these people NEW session IDs, even when they had one already. Unfortunately this means they are losing their shopping cart information, which is critically bad.

It *seems* like all of these users are using IE, but that might just be statistical probability. Users that have the problem are able to reproduce it regularly, but even duplicating their browser settings it is impossible to reproduce anywhere else so far.

Thus far I've tried many, many steps to resolve the problem. I changed the shopping cart itself from being session-based to a database. But this didn't help because the problem was that the 32-bit reference ID is being lost, not the actual data. I tried different settings for trans_sid, I've even tried manually appending the session ID and forcibly setting it on each page. But something's still going wrong. At some point, the client continues to generate a new session id and pretend the old stuff didn't exist. So then I took it to the next step and implemented a custom session handler. But it didn't help. I'm just about to tear my hair out on this because it doesn't make any sense. I'm not doing anything nonstandard with this website.

The only thing I have noticed is that most (if not all) of the problems do seem to happen with IE, and always (as far as I can tell) within HTTPS and never in HTTP. But it's not at the transition between the two that the problem happens, which I thought might explain it originally. We're running with an Apache server with a Thawte SSL cert.

[jatar_k]

Welcome to WebmasterWorld unipus,

funny you should ask this, myself and the sysadmin I work with have been playing around with this exact thing today. It is mildly disimilar in that ours occurs in one specific form.

We played around with php.ini a fair bit and the session settings. We were thinking tha one of the omitted settings may have tripped it up but that didn't help.

I tried putting a hidden field into the form and then setting the session id using

session_id($_POST['PHPSESSID']);
session_start();

but that didn't seem to help.

Can you isolate it to any one particular page/script that will constantly misbehave?

I have also started tracking all my session_start calls to see if I have accidentally corrupted one of them but haven't finished with that yet, it isn't a high priority.

I can simulate my particular situation by blocking cookies, it doesn't want to play nice with cookies off. It is an auth script that is killing it but the script is fine, it just can't connect them with the session data it seems.

I was also checking privacy settings and wondering if some other software might be nuking things.

I know it seems like I am hijacking this thread ;) but I am just running through some of the things I am trying to maybe give you something you didn't think of.

It is strange that it just disappears at some random point, is it time related?

>> I'm just about to tear my hair out on this because it doesn't make any sense.

I'm with ya on that

[unipus]

Can you isolate it to any one particular page/script that will constantly misbehave?

Well, yes and no. There is one page in particular that detects whether or not the session has been misplaced. So I went and hard-coded in the session ID, much like you've said there. I added my own variable, $sess, to the query string of every link. I changed the header code on every page from session_start() to session_start($sess) - after evaluating and confirming the existence of $sess, of course. And this works... sort of. Invariably, at some point, the id would still get lost, even when it was definitely sent in the query string. It doesn't make any sense... nor does it make any sense that I should have to do this, since this is the whole point of enable_trans_sid.

Like I said, it only happens to some people, and it's not reproducible anywhere else. So I suspect some sort of connection problem. Maybe a firewall on their end? But the people I've actually spoken to that have the problem deny that they have any sort of firewall, or ZoneAlarm, or anything like that.

Here's a few pages I found that describe the problem fairly well (including the one that originally led me here):

PHP bug report post [groups.google.com]
post here at webmasterworld [webmasterworld.com]

Unfortunately, contacting some of these people directly has yielded advice, but nothing that worked. Some of them seem to have corrected the problem, others either gave up or migrated their entire setup. Neither is an option for me.

[hughie]

I've not come across this problem before, my initial reaction would be to say that one of your pages that 1-5% of people visit is re-setting the session var somehow. But it seems you may have gone through all of those kind of problems so is probably not.

possibility 2 (again total guesswork) could be that you've run out of memory on your server to store sessions?

Possible work around would be to store each session in a database e.g.
session_id, session_time, Session_IP_address
every time a new page is visited re-set the session_time. If a session gets lost, before re-setting it check to see if that IP address had a session running in the past 1 minute(or whatever), if so, rebuild the session. if not start a fresh one.

Not perfect but it could help lower the percentage of lost sessions.

ta,
Hugh

[jatar_k]

You figure anything else out unipus?

I just let it slide because it was non critical and I just don't care that much. It got prioritized to the bottom of my very long job list. ;)

[unipus]

Unfortunately I haven't. At the moment I am playing with sending different caching headers, but really I'm just stabbing in the dark. But no complaints yet in the last day, so maybe I stabbed something successfully.

Sadly for me this problem is highly critical. Basically it amounts to turning away customers who had their wallets out, and has probably cost us thousands of dollars to date.

[unipus]

oh and hughie, thanks for the suggestion, but it seems like that would add a whole extra level of database activity to every single page load. And even then I generally don't trust IP-based methods. But as you said it might at least REDUCE the amount of loss, so if this keeps up it may become my last line of defense.

[hughie]

yeah, not perfect at all but always one for the sticking plaster over a leaking water pipe ;-)

if you ever figure it out, tell us what the problem was.

ta,
Hugh

[vincevincevince]

Are all your pages PHP? Or are you mixing .html and .php?
Just allow PHP to parse the .htm / .html pages and see if it fixes it, use AddType in your .htaccess

[unipus]

I don't see how that could possibly make a difference. A few included bits here and there (mostly menus, headers, etc) are .html files, but mostly they're all PHP.

[Mats]

Hi.

I have run into the same problem (I think). With IE at home, a new session id is generated every time. With IE at work and with Opera at home, it works fine.

I have reduced the problem to a small php file that just displays the session id. Displaying that file and repeatadly reloading it displays a new session id at each reload with IE at home, but displays the same session id with IE at work and woth Opera at home (in accordance with the above results).

My Further investigations showed that the problem was solved when I moved the session_start() call to before the initial html tags. See below. When session_start() is within the <body> </body> tags, it fails for some users all the time, but when it is put first in the file, the problem is solved.

Hopefully, this solves your problem also.

---------- Code that for some users never works ----
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Untitled Document</title>
</head>

<body>
<?php
session_start();
echo "Your session ID is <strong>". session_id() ."</strong>";
?>
</body>
</html>

----------------- Code that works fine --------------
<?php
session_start();
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Untitled Document</title>
</head>

<body>
<?php
echo "Your session ID is <strong>". session_id() ."</strong>";
?>
</body>
</html>

[unipus]

Well, I was never calling any HTML before initiating session start, but I did have a linked dependency:

my pages were all calling a "meta" html file which in turn was calling a "start" file. The start file had the call to session_start. I suppose it's possible that PHP may have been evaluating the remainder of the HTML page before initiating the session start... so I just recoded it all so that the "start" file is ALWAYS the very first line called and session_start() is always the first line on that file. Hopefully this works, since checking logs was making me nauseous and didn't seem to be getting me anywhere new.

[unipus]

Thanks for the thought, though. That had never occured to me and in a roundabout way it might be the same problem! I'll buy you any number of beers if this works.

[unipus]

Unfortunately I now have evidence that this problem continues to happen.

Any other ideas out there?

[DaButcher]

Try to add the SID in href and in form action..

eg:

<form action="?<?=SID?>" name="foobar" method="post">

<a href="page2.php?<?=SID?>" title="go to page 2">page 2</a>

If the client does not accept the cookie for the session, the session can be lost.