$_SESSION's working in I.E. but not in FF?

we5inelgr

Hi all,

I've got $_SESSION working in I.E., but they are not working in FF in this way (basic set up):

After successful sign in, some session variables are set, and then checked at various places afterwards.

While using Firefox, I look in Tools -> Options - Privacy [Show Cookies]

I can see the PHPSESSID cookie.

When I check for that PHPSESSID cookie on the filesystem, I can see that corresponding file...and in it are the $_SESSION[vars] that I'm setting.

However, I'm not able to access those $_SESSION[vars] while using Firefox, like I can while using I.E.

Any ideas why? 😕

P.S. I was using Firefox 20.0.1 (just now upgraded to version 21.0 - still has this issue) and I.E. 9

bradgrafelman

Try echo'ing out the [man]session_id/man on each page when you're using Firefox; does that ID value ever change from one request to the next? If so, your cookie isn't being propagated correctly. Are you perhaps changing hostnames at some point? Note that by default, a cookie created at "mysite.com" won't work if you navigate to "www.mysite.com" at some point.

we5inelgr

Hello and thanks for the reply and suggestion.

I echo out session_id() and it's the same across the pages being used/accessed.

The site name remains the same as well.

It's really strange. The data (vars) is there in the actual session file, and I.E. can pick it up. But FF can't.

Perhaps there is some kind of debugging tool I could use with FF to try and ferret this out?

bradgrafelman

Just to confirm... when you say "actual session file", you mean the file on the server in the PHP session directory, right? If the data is there, and you've confirmed the session ID is being output correctly, then the browser really doesn't come into play - the only item the browser needs to pass along (whether it be by query string, POST data, or in a cookie) is the session ID itself.

Have you tried doing a [man]var_dump/man on the $_SESSION array?

Weedpacket

I guess you mean that your PHP script can't pick up the session variables when you're using Firefox, but it can when you're using IE; neither browser ever gets to see the session variables, only the session ID.

we5inelgr wrote:
Perhaps there is some kind of debugging tool I could use with FF to try and ferret this out?

Look under "Tools > Web Developer". You'll find some there. There's also an option to "Get more tools".

we5inelgr

Weedpacket;11028619 wrote:
I guess you mean that your PHP script can't pick up the session variables when you're using Firefox, but it can when you're using IE; neither browser ever gets to see the session variables, only the session ID.

Thanks for the reply, and yes...that's what I meant.

Same php script, accessing the same php session file in the php session directory.

When the script is run using I.E., the contents of that session file can be read (by the php script) and verifications done with it and processing as expected.
When the script is run using FF, the contents of that session file appear not to be able to be read.

When I place a var_dump($_SESSION) in the php code, and run it with:

I.E. I get:

array(5) { ["varA"]=> string(16) "aaaaaaaaaaaaaaaa" ["varB"]=> string(32) "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" ["varC"]=> string(20) "cccccccccccccccccccc" ["varD"]=> int(1111111111) ...etc

F.F. I get:

array(0) { }

we5inelgr

bradgrafelman;11028617 wrote:
Have you tried doing a [man]var_dump/man on the $_SESSION array?

Thanks for the suggestion, please see post above for the output using the two different browsers.

bradgrafelman

And just to double check... you're going through the same hyperlinks/pages in FF that would set those session variables before you test for their existence, right? In other words, a session started and populated with data using IE wouldn't be resumed when switching to FF.

sneakyimp

we5inelgr;11028653 wrote:
Same php script, accessing the same php session file in the php session directory.

This might be totally off-base, but just because you have a session using one browser does not mean that session will be alive in the other browser. For example, I can login to amazon.com with Chrome but when I open Firefox, I am not logged into my account because the separate browsers store their cookies in separate locations -- and chances are that my server has given one session id to Chrome and a totally different session id to Firefox.

The basic idea is that a browser stores a cookie called PHPSESSID because the server asks it to at some point. This PHPSESSID cookie contains a value, typically some random hexadecimal number or base64-encoded random string of letters and numbers. Unless IE and firefox have the exact same value for PHPSESSID then they are going to have different sessions. I.e., one browser will be logged in and the other will not.

Weedpacket

sneakyimp wrote:
This might be totally off-base, but just because you have a session using one browser does not mean that session will be alive in the other browser.

Just to put another perspective on what sneakyimp says here; a "session" is something between two participants - the client (browser) and the server. Different server or different client == different session.

we5inelgr

I'm not using I.E. and F.F. concurrently or back and forth while each session file exists on the server. I'm doing this in an isolated fashion if you will.

This is being done with I.E. first and only I.E. with any session files deleted from the server. Then, after I confirm the php scripts have created and then are picking up the stored (on the server) session vars while using I.E., I close out I.E. and delete any session files from the server again (is only one, from the just completed testing using I.E.). Meaning, there now exists no session file(s) on the server.

Then, I use F.F. (with no pre-existing session file(s) on the server), and after the php scripts successfully create the session file and the session[vars] that I intend...the contents of that session file can not be read by the php script while using F.F.

When I echo var_dump("$_COOKIES");

In F.F., I get:

array(1) { ["PHPSESSID"]=> string(32) "ca9bde2634812c352990c2fdfa5e199a" }

In I.E., I get:

array(2) { ["slider1"]=> string(9) "slider1:0" ["PHPSESSID"]=> string(32) "9eecab137abebbcf220f4aca6b30cbbf" }

sneakyimp

I think the descriptions of your actions need to be more specific and it would be helpful to see some source code of the PHP files involved. E.g., what commands are you using to inspect session data files? How are you making sure that session files are removed? What PHP scripts are you visiting in what order and what is their source code?

Also, you may already know this but session variables are not stored in a cookie file. I'm a bit confused that data seems to get stored in the IE cookie but not in the FF cookie.

You may also want to delete all cookies for your domain -- sometimes cookie files get corrupted.

Regarding tools, FireBug is good for firefox -- it can tell you what cookies were sent with each file request.

we5inelgr

Doing more testing with just Firefox, I found a file in the php session location (on the server):

session_mm_cgi-fcgi716.sem

It's empty. Not sure what that is, perhaps some kind of bug "report?"

we5inelgr

by writing the session_id() into a file during different phases to the sign in process (instead of echo'ing out and causing header issues), and testing using I.E. and F.F., I can see that the session_id() is changing 3 times during my testing with F.F., and is not being changed at all testing with I.E. (all the rest of the php code remaining unchanged).

At least now I know why this is happening when I use F.F. and not I.E.

Now, I just need to track down why/where the code is creating 3 different session_id()'s.

It's pretty strange to me though, why this would be happening in Firefox and not in Internet Explorer. Why the code would be behaving different based on use of different browsers.

sneakyimp

Your server will create a new session ID if a browser fails to provide a recognized session id with a given request. It sounds like perhaps Firefox is neglecting to show up with a session id that the server recognizes. This might happen if Firefox was in private browsing mode or something.

If you install Firebug, a developer plugin for firefox, you should be able to inspect the exact request that firefox delivers to the server -- including any cookies that the browser sends along with the request. This should allow you to at least find out if firefox is sending the right session ID along with its request.

Rivet

This might be a silly question but ... have you tried running FF without any add-ons?

we5inelgr

Thanks for the replies.

The bigger picture was that I was trying to have a sign in page (& it's action page) to be on HTTPS and then after successful sign in, send the user back to HTTP. I was on a shared cert on the server I'm on and didn't want the user to be on that shared cert the entire time. More of a cosmetic thing and potential confusion (url would have a name that wasn't my site) to the users than anything else.

This would be similar to such sites as Yahoo, when you sign in (on HTTPS), if successful, you are back on HTTP.

This involved storing some info about the HTTPS session info in a db table, and upon a redirect, reading that table and setting HTTP session vars. Convoluted, I know, but I had it working in I.E., but just couldn't get it working when using F.F.

So, I went and got an SSL cert for my site. About 20-30% of the users on the site would be using HTTPS at any given time. Now I simply leave the user, who would normally sign in to the site, on HTTPS after good sign in.

sneakyimp

I don't think switching from HTTP to HTTPS and back should cause a session id to get lost. You should try to examine each page request by firefox in more detail. I've mentioned Firebug twice already and I'll mention it one last time. You can use it to inspect the exact request sent by the browser and determine if the cookie is being sent or not. e.g.:

Accept	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding	gzip, deflate
Accept-Language	en-US,en;q=0.5
Cache-Control	max-age=0
Connection	keep-alive
Cookie	bb_lastvisit=1342723463; bb_lastactivity=0; bb_userid=1234567; bb_password=76a76d76ae7676aee76ae76a098bbc; bb_userstyleid=15; bb_sessionhash=a78b34c65b123d51945efef88783564; 
DNT	1
Host	www.phpbuilder.com
User-Agent	Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0

See the Cookie section? That would show you what session id your browser is handing to your server with the page request.

Weedpacket

sneakyimp wrote:
I've mentioned Firebug twice already and I'll mention it one last time.

I've alluded to it as well.

bradgrafelman

And if you're using Chrome on Windows, it has its own built-in set of (very awesome) dev tools - just hit F12, Ctrl+Shift+I, or (via the menu) Tools->Developer Tools.