Forum Moderators: coopster
I'm using a LAMP setup and for the most part everything works fine. However, occasionally, users are being assigned new session ids even though their old ones are still valid. This happens without explanation. So far I've only seen it happen to IE (win and mac) and Safari users. It primarily seems to happen in https as opposed to http.
I have tried a LOT of solutions to this problem. I am now using a custom session handler. I have played around with the cache settings (admittedly I am poking in the dark with that, though). Nothing has worked. This problem comes and goes. Sometimes a week or more will go by without an instance. Sometimes it will happen half a dozen times in a day. I can't seem to find anything else that this might correlate to.
Ideas?
With the default handler, have you been able to catch it in the act of re-assigning? It would be interesting to know if the serialized session exists on disk when it happens. Maybe something like this before your session_start():
if (array_key_exists(session_name(), $_COOKIE)) {
if (file_exists(ini_get('session.save_path') . DIRECTORY_SEPARATOR . 'sess_' . $_COOKIE[session_name()]) {
...
}
}
On a totally different tact, are you outputting P3P compact privacy policy headers? No P3P plus some IE settings can cause cookies to be lost.
Here's our current P3P:
header('P3P: CP="ALL DSP LAW CUR DEVi PSAa CONi OUR IND PHY ONL UNI PUR COM CNT"');I'm not 100% clear on what the code you suggested is accomplishing. Obviously it would be useful to know if the session is stored in cookies, but it shouldn't matter, since use_trans_sid has been ON for a long time now. Even still, a user will often be assigned a brand new session id. Their old session is not erased; if I manually force the id, the user will regain their data. So I don't understand why this is happening.
I can tell you that the session definitely still exists in the database and that if I set a page to start with session_id([known session id]) the data is recoverable. Sessions are timed out after two hours, but many people are having this occur after five minutes or less. So the problem is in whatever is causing the server to assign a new ID when it's not needed.
Unfortunately I'm not entirely sure of how to further troubleshoot this at this point unless I can get someone on the phone again. At the moment I don't have anyone who seems particularly accessible to help.
(which brings up another point: I can mimic the version numbers and security settings of one of these users' browsers precisely, and still not be able to reproduce the problem)
I think you can test this more-or-less without user help by:
1) every time you start a new session, log that fact, along with the session ID and client IP.
2) every time you *check* for a session & don't find one, log the client IP, referring URL and the value of session_name() in $_REQUEST and $_COOKIE.
Depending on your traffic, you'll have to sift through a lot of logs. And some clients will have shifting IP addresses which will add more noise.
But with some log analysis hopefully you'll be able to connect the dots between 1) and 2) and find out when a user's session is being dropped, and, crucially, a big hint to where the problem lies.
I've setup a table to track every click in the system - and it is dropping and reassigning new session ids - forcing the user to login again.
The only thing that I've found right before the session info is lost - the URL has two PHPSESSID params, with the same values appended together.
The problem is that I can't recreate it! Even if I put PHPSESSID in the URL twice. I've tested on IE 6.0 (windows) and IE for Mac 5.22 and I can't get it to drop the sessions. But my clients have IE for Mac 5.23 and 5.16 - and it's happens to them a couple times a day.
I am following their exact steps - and simply can't get it to happen. I wrote a function to strip out any extra PHPSESSID that may have snuck into the url - and that isn't fixing the problem.
HELP!
I've tested on IE 6.0 (windows) and IE for Mac 5.22 and I can't get it to drop the sessions. But my clients have IE for Mac 5.23 and 5.16 - and it's happens to them a couple times a day.
Have you tried with the exact version? .23 and .16 are both downloadable from the Evolt browser archive.
Among other horrors, I regularly (daily!) see older Mac IE installations modify the url on request redirection- e.g. redirected to /foo?thingid=2 but IE will actualy request /foo?thingir=2 instead. I wouldn't be suprised at all if the browser was corrupting the PHPSESSIONID, especially if the URL in question involves any URL escaping. (%xx)
But - you're right - I should try it on other browsers.
BTW, I have tried to replicate customer actions with the identical browser release, with no success.
They have told me that they are not opening mult. windows - or logging on simultaneously at mult. workstations - or anything like that.
The only consistent thing I am finding in the logs is seeing the PHPSESSID param in the URL twice. But why does that happen? That's what is stumping me.
And - I do have one of the same problems you had - no one can sit down and go thru it with me.
I got this on Firefox after futzing around for about two hours. I echoed the SID to each page and it would change on the third page I hit - every time. Just before I put a gun in my mouth, I switched over to IE and it worked like a charm. It sucks, because I have to tell my client that all his visitors will have to use IE.
I've also wondered if this is some sort of firewall or ISP issue, but the people I've spoken to that have the problem insist that they have no firewall that they know of. And I wouldn't know what to do about that problem if it was.
Bookmarks.
As soon as you go to www.test.com (or whatever) - a session id is created and appended to the url.
www.test.com/login.php?PHPSESSID=12345abcde
And - at the same time, a session cookie is created on the users machine. But - some people had bookmarked this exact url:
www.test.com/login.php?PHPSESSID=12345xyz
-- so EVERYTIME they accessed the site via the bookmark, that same session id was put in the url. And it appears that the code - seeing that the sessid was there - did not create the cookie for that session. And then after a few clicks - when the cookie wasn't there - they got kicked out. And then they were assigned a new, valid session id - and everything was fine from there.
-- This problem would not occur with every site, of course, but this site in particular is secure - and requires a valid login and session in order to keep working within it. Once the session expires or is determined invalid, the users must relogin for security reasons.
-- This explained why some users were not having the problem at all. Turns out that the 3 or 4 users that had never been kicked out, didn't have the site bookmarked - they just typed it in everytime.
-- I'm not sure if this same type of problem would occur on PC's. I haven't tested that yet.
Hope this helps someone out there from the same headache.
For those who are wondering - the system is phpCollab.
I will go post this on their forums too.
My application also seems to occasionally forget a user's phpsessionid, and reassigns a new one in the middle of 'a session'.
I discovered that the user was entering my site via a link from an email. He wandered around for a while, and decided to switch back to his email application and re-entered my site via the same link.
Different browsers behave differently - and many start a new session when launching from a link in an email. Mine does not, but my user's does; hence, I was unable to reproduce this behavior on my own browser.
In any case, I now know to only distribute links in emails which point to pages that work as initiators of new sessions.
Hope this is helpful.
Cheers
Robert
that is helpful actually, thanks. I hadn't really thought of that scenario.
