php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23764 session spans 2 or more IE windows, PHP doesn't let me create a unique session
Submitted: 2003-05-22 18:38 UTC Modified: 2003-05-28 12:36 UTC
From: mfoxx at hotmail dot com Assigned:
Status: Not a bug Package: Session related
PHP Version: 4.3.0 OS: RH 6.2
Private report: No CVE-ID: None
 [2003-05-22 18:38 UTC] mfoxx at hotmail dot com
Let me first state that I know my version (4.0.6) is very old, and there are many problems with it.  There is a plan to upgrade, but in our situation at work, it requires coordination with several servers, some of which are offsite and out-source managed, and so we haven't been able to upgrade yet.  I have scoured the bug list (as I do everytime I encounter something weird/unexpected like this) to see if the problem I'm describing has been discussed and/or fixed in subsequent versions.  I did find several places where a similar topic was discussed, but my problem has a different bent on that, and shows itself in a different way. I would not be submitting this request unless I was confident that it has not yet been addressed in the bug forum or in subsequent versions.

I have the following situation, which appears to happen on all the current IE browsers (5+/6).  The following simple script loads into browser window "A".

myscriptA.php:
<?php
session_start();

if (!session_is_registered("test")) $test = "blah";
else $test .= "_more";

session_register("test");

echo $test."<br>\n";

echo session_id();

?>

<a href="myscriptB.php" target="_new">Launch B</a>



The following code describes the first version of myscriptB.php, which gets loaded into window "B" from the click in window "A":

<?php
session_start();

echo $test."<br>\n";

echo session_id();
?>

when you click the link in window "A", you get a new window, with myscriptB.php loaded into it, and as expected, the session has spanned to that new window, and $test = "blah", which is what is echo'd out.  Also as expected, the session_id() has spanned so whatever it defaulted to in window "A" is now printed out in window "B" as well.

If you go back to window "A" and you refresh the page, since $test stays in the session, it gets the string "_more" added to it, and so on the refresh window "A" prints out "blah_more".

Now, consider the case where I want window "B" to have its own session, while still being launched from window "A".  That way, I could independently destroy() either window's session or overwrite session variables or whatever, and not have it affect the other window's session.

Ostensibly, from the documentation, it seems that session_id() and session_name() should be able to be used to replace the current session's id or name with a new one. This would then in affect be creating a new session, in my understanding.

So, I changed myscriptB.php to:

<?php
session_id("newwindowB");
session_start();

$test = "newTest";

echo $test;
?>

The behavior that is expected is that window "B" will print out "newTest", and that window "A" variables will be untouched.

However, what happens is odd, two-fold. First, window "B" does print out "newTest". But, when you go back and refresh window "A", the session in window "A" has been "lost".  It's not even that window "A" prints out "newTest" as well, window "A" thinks it has no session at all, so it prints out just the first "blah". Weird. Then when you refresh window "A", it takes on the session from window "B" and window "A" NOW prints "newTest" and the session id that is printed is "newwindowB". Even Weirder.

The goal is for window "B"s script to be able to create its own session, and then at some point if the user chooses, have that "B" session destroy()'d.  Then the user would simply close window "B" and go back to window "A" and should have the session in window "A" still intact.

Why are these sessions inextricably tied together (I know it is surely something to do with cookies)?  Is there no way for PHP to correctly create its own NEW session at runtime, instead of just having to inherit something from the client?

Clearly, PHP is capable of creating its own session out of thin air when the window in question has had no session in it yet, so why can it not overwrite that and make a new session?  It seems that the documentation on session_id() is indicating that you are changing the session_id, and that means its a new session, in new files/cookies/whatever. but this is not what happens.

I've posted this on several different forums, and noone seems to understand what to do to make this work?  Am I crazy for thinking that PHP would be able to create a new session on demand? HELP!?

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-22 18:46 UTC] mfoxx at hotmail dot com
I should also mention that if you were to just open two seperate IE windows, and load myscriptA into one and myscriptB into the other, they DO function seperately, and so the sessions are not automatically spanned.

My ultimate goal is to have a way to have a session aware page launch a new window (that can also be session aware, with its own new session) that does NOT share the original window's session.

Everything I read seems that the intent is there to be able to on-demand create new sessions, and it stands to perfect reason that one might want to decide at some point in their PHP code that they wanted to break from any current session data (in cookies, memory, etc) and make a new session entry.
 [2003-05-22 19:07 UTC] magnus@php.net
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

As the report page tells you, upgrade first. 
 [2003-05-22 20:04 UTC] mfoxx at hotmail dot com
As I figured, you guys didn't read the whole thing. I specifically stated at the beginning that even though I was on an older version, others have had this problem in later versions, and the problem does not appear to have been identified or fixed in the change log or in the bug system.  I read every single post under the session bugs (took me like 6 hours) and saw nothing that specifically dealt with my problem. 

That's a canned response and a cop-out for you to just blame it on an old version of PHP unless you can tell me where its documented that it was fixed in a later version.  Since I already told you in my post that I have a logisitcal problem that prevents me from just simply upgrading right now, I think if you are so convinced it was fixed it would be nice and helpful if you would test the 2 very simple scripts on your updated version and see if you get the same thing as I do.
 [2003-05-22 20:05 UTC] mfoxx at hotmail dot com
How can you call this a useful system if you all take the easy way to answer everyone's question?
 [2003-05-22 20:08 UTC] rasmus@php.net
This is not a tech support system.  This is a bug system.  It is up to you to prove to us that there is a bug and not up to us to prove to you that there isn't a bug.  Why is it hard for you to test your "simple" scripts on a recent version of PHP?  Are you saying that you don't have a single development machine on which you can install the latest PHP and test this stuff yourself?  If so, that is definitely not our problem.
 [2003-05-22 20:16 UTC] mfoxx at hotmail dot com
I'm saying it seems wasted to install a whole new installation of PHP to test 10 lines of code, when someone with it already installed could test it in like 3 minutes for me and point me in the right direction.  

And noone said anything about you having to prove anything, I just expected maybe you'd have some common courtesy and either point out where it had been fixed, or test yourself to see if it had been fixed.  You took like 3 seconds to look at the 4.0.6 and just dismissed it.  That's sad and unprofessional.

Be that as it may, I'll play that game.  I'll waste my time to install the latest and greatest from PHP, and when I get the same problem, I expect to have some more decency shown toward a loyal and well-versed supporter of the language.
 [2003-05-22 20:30 UTC] rasmus@php.net
Look at the bug number for this bug report please.  Yes, this is the 23,764th report filed.  I don't know why you think installing a recent version of PHP and checking whether the problem still exists is a waste of your time.  You are helping us trying to solve *your* problem.  You damn well better be willing to put some effort into this and by whining that it is a waste of your time you are making sure that none of us are going to waste any of ours helping you.  We have 23,763 other reports we can go deal with.  

And yes, I have read through your entire report.  Why in the world are you not dumping the cookies that get sent from PHP and the ones that get sent from the browser and telling us what the cookie exchange looks like?  And what do the session files in your session directory look like for the two sessions?  Do a little bit of homework please and give us something to go on.
 [2003-05-23 09:22 UTC] mfoxx at hotmail dot com
OK, so I found an idle deval server with the same OS and php 4.3.0 (relatively much more recent) on it. Tested the test scripts on it. Let me state that in my first posting, I misspoke slightly about the behavior.  When I said that window "A" lost its session entirely when window "B" was launched, that was incorrect.  What actually happens is that window "A" looses its ORIGINAL session association, and immediately takes on the new session id set in window "B".  The two windows are apparently inextricably connected since one launched the other. :(

In any case, I still found some weird/unexpected behavior with the way the session files are created and updated.  Here's a step by step trace of what I did:


window "A", loaded with myscriptA.php - screen output:

blah
e373b944e16776e47a365d455f4fcc02
Launch B 


session file on server:

/tmp/sess_e373b944e16776e47a365d455f4fcc02
test|s:4:"blah";

************************************************************

clicking "Launch B", 
opens window "B", loaded with myscriptB.php - screen output:

newwindowB
newTest

now, two session files exist:

/tmp/sess_e373b944e16776e47a365d455f4fcc02
test|s:4:"blah";

/tmp/sess_newwindowB


notice the sess_newwindowB file is blank right now. WHY DIDN'T session newwindowB get the "newTest" string assigned to test and stored into that session variable?
As seen later, the behavior should be that any change to the session should get immediately (at the end of script execution) written back to the session file on the server, right?


************************************************************

leaving window "B" open, switch back to window "A", click refresh - screen output:

blah
newwindowB
Launch B 

both session files still exist:

/tmp/sess_e373b944e16776e47a365d455f4fcc02
test|s:4:"blah";

/tmp/sess_newwindowB
test|s:4:"blah";


notice NOW that sess_newwindowB, instead of getting the "newTest" in it from window "B", has "blah" in it from the refresh of window "A".

************************************************************

refresh window "B", output in window B stays the same, then refresh window "A" again - screen output:

newTest_more
newwindowB
Launch B 

it's now obvious that sess_e373b944e16776e47a365d455f4fcc02 has been abandoned and is not being updated. its data remains the same.

/tmp/sess_newwindowB
test|s:12:"newTest_more";

notice that sess_newwindowB has not only "newTest" in it, which was surely from the refresh of window "B", but on the refresh of window "A", "_more" was added to the end of the variable and written right back to the session file. 

This is different than in the second step when window "B" changed the session the first time, which apparently didn't change the session file immediately as expected.
 [2003-05-23 10:09 UTC] sniper@php.net
You never change the session name in your scripts,
so of course the last accessed script is the active one.
(the cookie name is propably PHPSESSID always.)

Please ask further support questions elsewhere, this is not a bug.

 [2003-05-23 11:21 UTC] mfoxx at hotmail dot com
Ya know, if the session_name() was the only problem, and the session_name() is by default globally always "PHPSESSID", then why would simply opening up a new internet explorer browser window manually and loading myscriptB.php into it NOT have that behavior?  I'll tell you why, cause its a combination of both the session_id and the session_name needing to be different.

Clearly, the PHP documentation doesn't spell this out in any detail, and so I will be submitting a request to them to add some description of how to correctly start a new session and abandon any old or inherited one for that window.

That's not an easy, intuitive, or simple concept that any old programmer would catch right away --- that two seperately opened windows would have their own unique session_id, and therefore the common PHPSESSID name wouldn't matter, whereas spawning a child window through an <a href> tag would copy over the default session_id and so the only way to diffrentiate in that case is to change not only the session_id but the default session_name as well.

You almighty PHP gods clearly knew that, since you responded to me by saying "so of course the last accessed script..."  Us lowly PHP minions though aren't as well versed in all the ins and outs.  Reading less than clear documentation on the subject, as well as posting the same question to several different forums, and having NOONE that understood that quirk, clearly it appeared to me to be unexpected behavior, ie A BUG.

I apologize for so severely wasting your time. I wish at first glance someone might have read a little closer my original post (cause my omission was clear and obvious then) and pointed it out, instead of taking the easy way out and just blaming it on my older version of PHP. That was by beef in the the first place, that it didn't appear to be version related, and I was right.  It's your bad handling that escalated this discussion beyond a simple support open-and-close case.

Your collective self-righteous and condescending attitude doesn't help anyone here. You can't possibly expect that every single USER of PHP would be so well versed in all the insides of PHP, like looking at session files and cookies and doing traces, etc.  People of all different levels of knowledge come to the PHP website, and its several different tools, FOR SUPPORT.  I guess you assume otherwise since we don't really buy PHP like we would a product from microsoft.  That doesn't just let you off the hook, free to be rude and unhelpful to those that are genuinely seeking assistance.

The bug reporting tool is clearly focused on documenting unexpected or buggy behavior and trying to find out the solution to it.  The trouble is that you feel your job is not support in any sense, and so you assume initially that every post here is BOGUS until we the inexperienced find a way to prove otherwise.  "Guilty until proven innocent".  Very poor public relations skills on all your parts.

It's rude to make someone feel it was a huge inconvenience  that they stumbled (incorrectly) into the bug reporting tool for this problem (when its clear and logical that given the info and documentation I had it SEEMED like a bug). All you had to do was politely point out my ommission and get me in the right direction.

I was wrong, it wasn't a bug. But you were wrong, it wasn't version related either.  I have a solution now, and I'm wiser for the wear. But I have lost all respect for your team because of your poor people skills handling.  I'll tell you what's really "Bogus" around here, its your credibility.
 [2003-05-23 11:32 UTC] rasmus@php.net
Actually, the fact that you don't buy PHP gives us all the freedom in the world to be rude and unhelpful.  Compare the result of all this with you having submitted a bug report to Microsoft.  They would have politely ignored you.  We rudely solved your problem within 24 hours.  Which would you rather have?  You are in no position to complain here and I would advise you to stop flaming the hands that feed you.


 [2003-05-28 03:44 UTC] heng at yahoo dot com
even you using other language like micro$oft' ASP, you also
will get the same result. So no blaming to php, as rasmus
said "Do a little bit of homework please and give us
something to go on."
 [2003-05-28 12:36 UTC] mfoxx at hotmail dot com
Just for the record, and for posterity who might read this thread and wonder, the solution was to change both the session name AND the session id BEFORE calling session_start() in the first script loaded into the new window. Thereafter in that new window (popup), before each call to session_start(), you only have to change the session name (otherwise it will default back to the "PHPSESSID").

This gave me the results I expected, the problem really was that it was not a correctly documented process, and so it appeared to be a bug at first. I have since submitted this to the documentation team to have them consider clarifying their documentation.
 [2003-06-13 16:28 UTC] ky at jelly dot com
the ice caps are melting, nyah nyah nyah




the world is drowning, nyah nyah nyah
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 23:01:26 2024 UTC