PHP session doesn't work with IE

Question

I have a site made with php which uses server side sessions throughout the site.
In fact, it's a site with a user login which depends on session variables and if there were a problem with all session variables, no pages would load at all.

On the site, there's an iframe that holds a feed of little messages from other users.
Those little messages have clickable photos next to them that open the user's profile.
Now, each page requires some formatting to open the user's profile on that specific page...there's really only a few problem pages, but those pages have to have the onclick functions formatted a little differently or they break the page.
So I set a session variable on each page ($_SESSION["current_page"]) that lets the feed know how to format the clickable photos. Now Firefox, Opera, Chrome, Safari all work as they are supposed to.
But IE6 and IE7 are having problems on the pages that require special formatting.
So after pulling my hair out a bit, I eventually got around to printing my session variables form the server.
And lo and behold, on the special pages, ($_SESSION["current_page"]) is always set to "main" instead of "special1" or "special2".

I printed the same session variable in Firefox and all the other browsers I mentioned and they print out "special1" or "special2" as they're supposed to.
Can anyone think of something - possibly related to the fact that the feed is in an iframe??? - that would cause IE to treat server side session variables differently or somehow launch page "main" silently in the background?
I have checked the feed very carefully for any reference to page "main" - it doesn't seem like there's any ways it's loading that page.

this doesn't make sense to me.

Solution 1

I thought some people might find the solution to this problem interesting. Fiddler certainly helped here. Thanks to Fiddler, I could see that I was, in fact, hitting the page main.php (thus setting the session variable moments after setting it on the target page), but the server was defaulting there after getting a 302 on the root of the site. This was all happening silently in the background, and before my onload="" javascript ran.

So I was sure something on those pages was causing an error, but not a catastrophic one.

here it is: <img src= "" >

IE was freaking out about the blank src attribute and hitting the server root and the defaulting to page main. I don't fully understand the mechanics happening here. I also don't understand if this is how IE is supposed to behave (it is a malformed img tag after all) or not. Is this a bug?

Solution 2

Check the name of the server machine. IE has problems with machine names that contain '-' or '_' - they cannot maintain a session! I've had this problem twice in the past, and it always takes me weeks to figure out, and I'm shocked IE hasn't fixed it.

Just rename the machine to have no strange characters! You can get it working if you just use the IP address of the server in the url to test.

Solution 3

IE has cookie issues with it's handling of iFrames which maybe causing the session issue you mention, take a look at these links

http://adamyoung.net/IE-Blocking-iFrame-Cookies

http://gathadams.com/2007/06/25/how-to-set-third-party-cookies-with-iframe-facebook-applications/

http://nileshtrivedi.in/blog/2008/09/01/iframe-cookies-and-internet-explorer/

Solution 4

Try testing the page while using some sort of monitoring proxy (I use Fiddler) and see what pages the browser requests. That might give you some clues to what's going on.

Also, try capturing the requests/responses from different browsers and see what IE is doing differently (order of requests, content of requests?).

To pinpoint the problem, can you rewrite the code without using SESSION (it's mentioned in one of the other answers)? Maybe IE is accessing the pages in different order than other browsers? Maybe it is requesting the main page more than once, which means that the session var is set to "main"? Without session variables, the pages won't affect each other's state.

Solution 5

In most cases, this php line at file begining will be enough:

header('P3P: CP=”NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM”');

If it isn't, for IE7 you may also try:

header('P3P: CP=”NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM”');

header('Set-Cookie: SIDNAME=ronty; path=/; secure');

header('Cache-Control: no-cache');

header('Pragma: no-cache');

And if that doesn't work for IE6, you may use GET params for session ID:

header('location: land_for_sale.php?phpSESSID='.session_id());

View more solutions

Comments

[Kieveli]

Re-writing a web app isn't always an option. Not only that, but it doesn't solve the original problem - just changes everything around it. Sean: Did you ever find a cause or solution?

[Piskvor left the building]

Kieveli: Good points. I wanted to suggest changing to a SESSION-less code to see if the problem persists. If it does not, it gives you a hint where to focus. Of course, if the app uses sessions pretty much everywhere, rewriting it just to pinpoint the problem is rather inefficient.

[Piskvor left the building]

Actually, that's "broken as expected": DNS names are not supposed to contain underscores (as per the RFC). All other browsers tolerate them, but IE, in its infinite wisdom, just silently drops cookies of such sites. No indication, no nothing. Priceless.

[EricLaw]

"Issues" isn't quite a correct summary. IE deliberately constrains cookies in cross-domain IFRAMEs unless a P3P Policy is present.

[EricLaw]

For legacy/historical reasons, IE treats the empty url "" as "/", which results in the HTTP request for the root URL. In your case, this is problematic because that request results in the setting of a cookie which changes your application's state.

[Paul Carlton]

@EricLaw-MSFT- A little late, but this explains exactly the issue recently had.

[jodeci]

We just spent 3 days tracing a session problem back to this. At least now I know why...

[Jasmo]

That was wonderful knowledge. The most irritating thing is that even IE's developer tools are just quiet.

[andr111]

@Sijin Thank you so much! You saved my day!

[Patrick]

As if I needed another reason to hate IE. We have dynamic subdomains on our website for customers to have their own profile pages, and it was all working fine until demo day when The Boss put in an underscore and everything broke.

[jcanker]

Old question, but for those looking for an answer today, I can confirm this as a likely cause. In my project I had started keeping the current version as the machine name, e.g. 6_3.myproject.com, 6_4.myproject.com. Once I did that the Location() in my login processing script stopped passing the PHP $_SESSION info and started a fresh $_SESSION. I spent a ton of time trying all the different solutions to no avail. Reading this made me realize that IE broke when switched to the new naming convention. Using 6dot4.myproject.com works fine.

[John Smith]

11.0.9600.17691 still causes it! Ive just tested it!

[Raptor]

machine name ... do you mean any part of FQDN ?

[Wadih M.]

In my case it was because I was using setcookie() with secure = true and trying to login with http instead of https