ID: 23764
Updated by: rasmus@php.net
Reported By: mfoxx at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: RH 6.2
PHP Version: 4.0.6
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2003-05-22 20:05:48] 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:04:44] 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 19:07:47] 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 18:46:56] 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 18:38:20] 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!?
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=23764&edit=1