ID: 39107
User updated by: misc05 at blueyonder dot co dot uk
Reported By: misc05 at blueyonder dot co dot uk
Status: Bogus
Bug Type: Session related
Operating System: Linux
PHP Version: 4.4.4
New Comment:
"This is really a support issue that should be aired in the
php-general
mailing list, but I'll drop a couple of hints here anyway."
How can it be? This is a bug and a big one affecting sessions in an
obscure and difficult to track down manner.
"(i) if you're relying on cookies to pass the session-id, that cannot
work as cookies set at example.com can't be read at www.example.com"
1. I am not relying on cookies to do anything.I dont set any cookies at
all. I am relying on PHP to generate a single session-ID for a single
session.
It does not - that is a bug.That is what I've reported.
2. example.com and www.example.com are the same domain.
A browser enters example.com and navigates to the first piece of code
listed above - this generates one session.
This code sends them to the second page on the same site/domain (as you
can see) and this generates a second session.
This is clearly incorrect behaviour as in session 1 PHP thinks the host
is example.com and in session 2 (which shouldnt even exist) it thinks
the host is www.example.com.
PHP has incorrectly decided it's now using a different host.
Entering this domain at any page with www.example.com then navigating
to the code above generates one session ID and correctly echoes the
variable.
Now close your browser and re-start it.
Entering the same page with example.com then navigating to the code
above generates 2 sessions and 2 session-id's and obviously looses the
variable as a result.
It couldnt be any clearer that this is not correct behaviour.
Try the code.Look at the value of "HOST" in PHPSESSID and the number of
PHPSESSID's generated each time.
"session_set_cookie_params function call. Which takes similar
parameters
as setcookie. With this function you should set the cookie domain
scope
to "example.com" instead of the default current domain."
Thanks - I'll give that a go of course - but my expectation is by doing
this the bug will simply operate in reverse?
But normally nobody needs to do this before every request and before
every session_start() so if thats the fix - its another indication of a
bug not a support issue.
"(ii) PHP's URL-rewriter also doesn't work, for similar security
reasons,
for URLs that are at a different apparent domain (nor, come to that,
for
any URL in header()!).
"
I would neither want nor expect it to - that is not the issue.
"(iii) therefore you have to pass it manually as either a GET or a
POST
parameter; session_name() and session_id() are useful here."
There should be no requirement to pass anything.That's the entire
purpose of PHPSESSID in the first place!
1 connection to 1 host should generate 1 session not 2. There should be
no need to create extra sessions and pass names or id's about. The
second session shouldnt exist.
PHP needs to be corrected so it doesn't think example.com and
www.example.com are different host domains.
Try the perfectly correct code above - and you tell me what you get for
each attempt.
Previous Comments:
------------------------------------------------------------------------
[2006-10-17 14:56:56] [EMAIL PROTECTED]
This is really a support issue that should be aired in the php-general
mailing list, but I'll drop a couple of hints here anyway.
(i) if you're relying on cookies to pass the session-id, that cannot
work as cookies set at example.com can't be read at www.example.com
(ii) PHP's URL-rewriter also doesn't work, for similar security
reasons, for URLs that are at a different apparent domain (nor, come to
that, for any URL in header()!).
(iii) therefore you have to pass it manually as either a GET or a POST
parameter; session_name() and session_id() are useful here.
------------------------------------------------------------------------
[2006-10-17 12:28:50] misc05 at blueyonder dot co dot uk
No eric - the issue is neither complicated nor is it bogus.
Try the simple code I placed in the first message and you will see 2
sessions started if the site in not originally accessed using www.
pre-pended to the address instead of one session.
QUOTE:
When accessing "example.com", the same session will be available at
"www.example.com".
This is not true and is exactly what I'm reporting.
Connect to "example.com" and the second file above (store.php) will
have a different session to the first file.
------------------------------------------------------------------------
[2006-10-17 11:48:46] eric at footsteps dot nl
Nigel, I'm not sure wether I understand your issue, but it seems to be
a bogus.
When accessing "example.com", the same session will be available at
"www.example.com".
Hoewever. When accessing "www.example.com", the sessions cookie set
there, is outside the scope for "example.com" which is fixed by the
session_set_cookie_params function call. Which takes similar parameters
as setcookie. With this function you should set the cookie domain scope
to "example.com" instead of the default current domain.
If the PHPSESSID cookie would be correct for both domains but the
session is just "lost" (which prob. trigger php to regenerate a session
id) you should check what "session_save_path" both sites use. Your
server may be using different save paths for both subdomains.
Good luck and regards,
Eric
------------------------------------------------------------------------
[2006-10-11 14:42:32] misc05 at blueyonder dot co dot uk
Technically I'm intregued but its way over the top surely tony?
There must be a better way to prevent a spurious sessionID than having
two copies of everything running? I doubt my ISP would like the idea
too much either...
Do we know where PHP gets the host value to put in the PHPSESSID in the
first place? Could I perhaps just change the value in there before the
first session is created ?
(I did try changing $_SERVER['HTTP_HOST'] but that didnt do it.)
nigel.
------------------------------------------------------------------------
[2006-10-11 09:53:40] [EMAIL PROTECTED]
You don't have to touch a working site or a working Apache.
PHP can be installed locally or using different Apache on different
port.
------------------------------------------------------------------------
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/39107
--
Edit this bug report at http://bugs.php.net/?id=39107&edit=1
