|
|
Posted by Andy Hassall on 11/01/06 13:05
On Wed, 01 Nov 2006 11:58:31 GMT, readme@now.com wrote:
>In article <ksrbk29ie6kcjoakvc5h6do93bqgd9vsbv@4ax.com>, andy@andyh.co.uk
>says...
>> What do you suggest as the solution? That all session cookies should have
>> their domain set to the TLD of the host issuing them? Then you end up with the
>> sessions leaking across domains, which is much worse.
>
>You seem confused as to what PHP uses to track sessions. And the
>difference between a host and a domain. PHP is using hosts, at least it
>calls it a host in PHPSESSID
Where does it do this?
>You can waffle on all you like but the bug is there - its hard, its
>simple to reproduce,
Please post a reproducable test case and submit it to http://bugs.php.net
>its all because PHP can't determine the host name its connected to
>accurately and provides 2 values for the variable "HOST" in PHPSESSID
>instead of one.
What does this statement mean? There are zero variables named "HOST" in
"PHPSESSID", the statement doesn't even make sense - there's nothing "in" the
PHPSESSID cookie, other than the session ID.
Cookies have a "Domain" attribute, which if left blank means it's only sent
back to the host from which it originated. If it's set, then it's used as a
tail-match on the hostname, so the cookie can apply to a domain (or subdomain)
and all lower-level subdomains.
PHP doesn't sent the domain parameter (by default, if you want this you can
change the settings), so sessions are per host, and rely on the cookie
specification's (correct) interpretation of this.
Earlier I posted an example Set-Cookie header with the output from a typical
session cookie, it doesn't have a "host" in there - it can't do, since that's
not part of the cookie specification.
Post some code or headers captured from PHP to demonstrate what you're on
about.
--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Navigation:
[Reply to this message]
|