ID: 23764
User updated by: mfoxx at hotmail dot com
Reported By: mfoxx at hotmail dot com
Status: Bogus
Bug Type: Session related
Operating System: RH 6.2
PHP Version: 4.3.0
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2003-05-28 03:44:02] 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-23 11:32:10] [EMAIL PROTECTED]
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-23 11:21:59] 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 10:09:48] [EMAIL PROTECTED]
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 09:22:33] 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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23764
--
Edit this bug report at http://bugs.php.net/?id=23764&edit=1
