views:

5587

answers:

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.

A: 

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
+6  A: 

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
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
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
A: 

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

R. Bemrose
A: 

fiddler is great! thanks. I am seeing some strange things in there. I believe the designer put a fake ad server in an iframe in there that refers to page main (somehow). I am generating a few things I need to look into. Nonetheless, the fact that this is only happening in IE is bizarre and I still don't understand it.

sean smith
+3  A: 

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
"Issues" isn't quite a correct summary. IE deliberately constrains cookies in cross-domain IFRAMEs unless a P3P Policy is present.
EricLaw -MSFT-
+6  A: 

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
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
+1  A: 

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: '< i m g src= "" > ' - (I typed spaces between img so this wouldn't get chopped out)

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?

sean smith
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 -MSFT-
A: 

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.

A: 

thanks Kieveli. You saved me a lot of time:)

robb
A: 

may be its session.cookie_lifetime, i have face the same problem i update session.cookie_lifetime: 4500 to session.cookie_lifetime:0 means session cookie never expire un till browser shutdown

dotcolor
A: 

< ? PHP

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'); ? >

use this on top of the page to fixed IE7

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

use ?phpSESSID='.session_id() to your location : to fixed IE6

RAT
A: 

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
A: 

Hi All

I am facing some serious problem with IE both 7&8.

Whenever i use session variables in my if condition it is going to else condition. I am really in great trouble.

I am doing somthing like this

If($total_rec == 0){

Some other code

some session variables

}else{

echo("something");

}

Every time i am using session variables it is going into else after doing execution from if condition before session variables or use of session variables.

Regards, Shahzad

Help others so God will help you

Shahzad Jameel