We have a local intranet site that everyone on the network uses. Maybe 5% (or even less) of the users that use the site have problems where the session isn't stored properly.
I've tried defining a path manually (C:/Coookieess) and checking to see what's going on. Whereas most users' sessions are created and remain just fine, on the affected machines it seems that it either forgets the cookies are there or it can't read them, and then goes on to create a new cookie almost every time a page is refreshed.
Things to note are...
I've tried messing with the security settings in IE too, changing the cookie security to allow all cookies/sessions, but no luck on that either unfortunately :(
Any help would be amazing. I'm really stuck on this.
Thanks!
A new cookie can get created when the site doesn't perceive one to be present or passed along from the previous request...
Is there anything about the site, your network or your clients that is causing the cookie hash to not be propagated between requests?
Use an HTTP analyzer (fiddler, nettool) to find out.
Not really got enough info to go on, but one thing that might be happening is that if you're storing the session in a cookie, you might have ended up with a cookie too large for IE to handle.
The definition of "Too Large" varies from browser to browser and OS to OS, though.
Just a random idea, and probably not relevant, but worth mentioning just in case - are the date and times set correctly on the computers you are having problems with?
any chance your internal domain has an underscore in it? i.e. http://dev_server.example.net
Usage of underscores as DNS characters is kind of hazy. FF/Safari will work just fine, but IE will fail to set a cookie if it comes from a domain with an underscore
Most public registrars will prevent you from using bad characters, but internally there's nothing stopping you.
We came across an issue a fair while ago that would appear to be the same as this - sporadic appearance, only affecting older IE users.
At the time any resources or commentary was quite hazy, so we were never fully able to diagnose the issue - the closest information we found was to do with IE not playing nice with g-zipped data.
Anyway - solution we found that fixed our issue -
header ("content-type: text/html; charset=utf-8");
Set your site to send a P3P (compact security policy) header.
One other thing you might want to check: are they using a proxy of any sort?
One of the PHP projects I worked on seemed to have troubles with sessions when the app was run on the intranet. Turned out that all of the IE installations had been set up to run through the corporate proxy which seemed to screw up every now and again...
Could it be that 5% of the users have user information that, when retrieved from the cookie, disrupts the proper reading/decoding/parsing of the cookie server-side?
I had the exact same issue and found that adding the P3P header before starting the session corrected it.
header('P3P: CP="IDC DSP COR CURa ADMa OUR IND PHY ONL COM STA"');
session_start();