14

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.

CSchulz
  • 10,882
  • 11
  • 60
  • 114
seans
  • 793
  • 2
  • 7
  • 19
  • To anyone else having this problem, I recommend completely closing down IE and re-opening it. This was happening to me in IE10, and I spent about half an hour trying all the solutions below to no avail. About 1 in 10 times the session would stay alive for long enough for me to log into my site, and then die again. After restarting the browser, everything works fine. – mpen Aug 05 '13 at 19:45

12 Answers12

31

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.

Kieveli
  • 10,944
  • 6
  • 56
  • 81
  • 16
    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. – Piskvor left the building Jan 02 '09 at 10:58
  • 1
    That was wonderful knowledge. The most irritating thing is that even IE's developer tools are just quiet. – Jasmo Dec 23 '11 at 07:17
  • 1
    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. – Patrick Apr 04 '13 at 16:22
  • 1
    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. – jcanker Mar 10 '15 at 11:42
  • 1
    11.0.9600.17691 still causes it! Ive just tested it! – John Smith Apr 11 '15 at 22:22
  • *machine name* ... do you mean any part of FQDN ? – Raptor Aug 18 '15 at 10:47
  • In my case it was because I was using setcookie() with secure = true and trying to login with http instead of https – Wadih M. Apr 14 '21 at 19:03
10

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/

Sijin
  • 4,530
  • 21
  • 22
  • 4
    "Issues" isn't quite a correct summary. IE deliberately constrains cookies in cross-domain IFRAMEs unless a P3P Policy is present. – EricLaw Jun 30 '09 at 20:53
  • @EricLaw-MSFT- A little late, but this explains exactly the issue recently had. – Paul Carlton Sep 26 '11 at 18:29
9

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.

Piskvor left the building
  • 91,498
  • 46
  • 177
  • 222
  • 2
    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? – Kieveli Nov 26 '08 at 15:59
  • 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 Nov 27 '08 at 14:15
3

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());
sinacos
  • 3
  • 2
RAT
  • 31
  • 2
3

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?

Prof. Falken
  • 24,226
  • 19
  • 100
  • 173
seans
  • 793
  • 2
  • 7
  • 19
  • 1
    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. – EricLaw Jun 30 '09 at 21:01
  • We just spent 3 days tracing a session problem back to this. At least now I know why... – jodeci Dec 08 '11 at 09:18
2

I found if you added header('P3P: CP="CAO PSA OUR"'); to the top of your doc. It seems to have fixed the problem.

Raptor
  • 53,206
  • 45
  • 230
  • 366
David Stone
  • 21
  • 1
1

I had this problem, and it was due to the date on my dev box being out. Firefox didn't mind, IE and chrome were seeing the session as being expired as soon as it was set.

seb
  • 11
  • 1
1

I have the same problem and it's SOLVED now.

The blank or empty attribute's values of any IMG tags cause the problem. For me, I used JavaScript to change IMG object's source to an empty value. Doing that could also make the problem.

Matt
  • 74,352
  • 26
  • 153
  • 180
encanodon
  • 11
  • 1
0

I had the same problem with ie7 and this is what I do:

If you have this problem using a IIS or Apache in Windows Server, look at the URL where you are redirecting it must be writed in the same way as the URL where you was before the redirection.

For example: site.com/pages/index.php redirection to site.com/Pages/index2.php is going to loose the session in IE7 because the capital letter in Pages.

0

Maybe it's session.cookie_lifetime. I have faced the same problem. I updated session.cookie_lifetime: 4500 to session.cookie_lifetime:0. This means the session cookie never expires until the browser shuts down.

WEFX
  • 8,298
  • 8
  • 66
  • 102
dotcolor
  • 1
0

If I understand it correctly, you are trying to use a session variable to pass data from a page to pages within iframes on that page? This doesn't seem a good way to go about it - why not just pass a GET variable into the iframe url i.e. ?current_page=special1 . I would think this would be more reliable as it does not rely on session state.

Remember also that the session variables will be the same for several pages of the same site that are open on a user's PC (e.g. on multiple tabs), which could cause odd behaviour.

Tom Haigh
  • 57,217
  • 21
  • 114
  • 142
0

Session data is stored on the server side, not the client. I would check the other pages, where this value would be set.

Powerlord
  • 87,612
  • 17
  • 125
  • 175