sessions and domain names

[magic_hat60622]

Hi all. I've got an app that dumps a user id into a session after
successful login. the login page is http://www.mydomain.com/login.php.

If the user visits pages on my site without the www (i.e.,
http://mydomain.com/foo.php), the session works fine and login state is
maintained.

If he visits http://www.mydomain.com/foo.php, the app drops the
logged-in state.

Any idea how to fix this? I'm running php 4.4.1 w/ linux apache.

[Kimmo Laine]

Re: sessions and domain names

"magic_hat60622 " <magic_hat60622 @yahoo.comwrote in message
news:1161906844 .922031.88670@i 3g2000cwc.googl egroups.com...

Hi all. I've got an app that dumps a user id into a session after
successful login. the login page is http://www.mydomain.com/login.php.
>
If the user visits pages on my site without the www (i.e.,
http://mydomain.com/foo.php), the session works fine and login state is
maintained.
>
If he visits http://www.mydomain.com/foo.php, the app drops the
logged-in state.
>
Any idea how to fix this? I'm running php 4.4.1 w/ linux apache.

Sessions are per domain. For www.mydomain.com there is one session, and for
mydomain.com there is another. Redirect all users from www.mydomain.com to
mydomain.com or vice versa. Make sure the domain is always the same. so that
it doesn't change on the way. That way they will always use the same
session.

--
"Ohjelmoija on organismi joka muuttaa kofeiinia koodiksi" - lpk
http://outolempi.net/ahdistus/ - Satunnaisesti päivittyvä nettisarjis
spam@outolempi. net | rot13(xvzzb@bhg byrzcv.arg)

[readmy@otherlips.com]

Re: sessions and domain names

In article <6ak0h.38690$3l 5.205@reader1.n ews.jippii.net> ,
spam@outolempi. net says...

Sessions are per domain. For www.mydomain.com there is one session, and for
mydomain.com there is anothe
>

A session is supposed to be a session with a particular host.

Actually PHP uses host names for sessions if you look in PHPSESSID but it
puts the domain name in by mistake. Hence his problem.

Now that all "domains" are being registered both with AND without the
particular service name (WWW FTP etc) - IE as host names - this is going
to be a big problem for PHP if it isn't sorted real soon.

You can see historically why the bug hasn't mattered but things have
changed in the domain registration business and now it matters a great
deal.

I'm suprised it hasn't been reported more generally. I've seen reports on
ecommerce web sites about mysterious failures, I wouldn't be at all
suprised if this wasn't connected.

[Jerry Stuckle]

Re: sessions and domain names

readmy@otherlip s.com wrote:

In article <6ak0h.38690$3l 5.205@reader1.n ews.jippii.net> ,
spam@outolempi. net says...
>

>>Sessions are per domain. For www.mydomain.com there is one session, and for
>>mydomain.co m there is anothe
>>

>
>
A session is supposed to be a session with a particular host.
>
Actually PHP uses host names for sessions if you look in PHPSESSID but it
puts the domain name in by mistake. Hence his problem.
>
Now that all "domains" are being registered both with AND without the
particular service name (WWW FTP etc) - IE as host names - this is going
to be a big problem for PHP if it isn't sorted real soon.
>
You can see historically why the bug hasn't mattered but things have
changed in the domain registration business and now it matters a great
deal.
>
I'm suprised it hasn't been reported more generally. I've seen reports on
ecommerce web sites about mysterious failures, I wouldn't be at all
suprised if this wasn't connected.

example.com and www.example.com are, by definition, two different hosts.
The fact they resolve to the same physical server is immaterial. PHP
is 100% correct in its operation.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[readmy@otherlips.com]

Re: sessions and domain names

In article <W_GdnTmEc5nxPN _YnZ2dnUVZ_sudn Z2d@comcast.com >,
jstucklex@attgl obal.net says...

>
example.com and www.example.com are, by definition, two different hosts.
The fact they resolve to the same physical server is immaterial. PHP
is 100% correct in its operation.
>

No

example.com and www.example.com are the same host by both fact and hence
definition. It is the domain being addressed not necessarily a physical
machine I agree. However...

The fact is that using www. as a prefix to a domain in order to
address a web server on that host may not be formal syntax but it is
formal by dint of common usage. Common usage for some time has been to
address the same host in either manner. Anyone reserving a domain today
will have both assigned and resolved as the same address making them
interchangable.

It is PHP that calls this a host and then provides 2 different answers as
to what that host is called during the same connection. The fact that it
comes up with 2 different answers to the same question during the same
connection should be telling you something?

That is a bug. And as big as a bug can get.

This makes PHP very much incorrect.

This is how the internet works. PHP needs to address this.PHP cannot
generate reliable sessions for all users until such time as this is
fixed.


In the mean time how about telling him how to avoid the bug?

[Andy Hassall]

Re: sessions and domain names

On 26 Oct 2006 16:54:04 -0700, "magic_hat60622 " <magic_hat60622 @yahoo.com>
wrote:

>Hi all. I've got an app that dumps a user id into a session after
>successful login. the login page is http://www.mydomain.com/login.php.
>
>If the user visits pages on my site without the www (i.e.,
>http://mydomain.com/foo.php), the session works fine and login state is
>maintained.
>
>If he visits http://www.mydomain.com/foo.php, the app drops the
>logged-in state.
>
>Any idea how to fix this? I'm running php 4.4.1 w/ linux apache.

If you want to force the session cookie to apply to a wider scope, i.e. to
apply for the mydomain.com domain instead of just the host that issued it, then
you can use session_set_coo kie_params to set the domain.

This may cause problems if you have other subdomains aside from the "www" one,
unless you really do want sessions shared across all of them.

--
Andy Hassall :: andy@andyh.co.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Andy Hassall]

Re: sessions and domain names

On Fri, 27 Oct 2006 15:06:03 GMT, readmy@otherlip s.com wrote:

>In article <6ak0h.38690$3l 5.205@reader1.n ews.jippii.net> ,
>spam@outolempi .net says...

>Sessions are per domain. For www.mydomain.com there is one session, and for
>mydomain.com there is anothe

>
>A session is supposed to be a session with a particular host.
>
>Actually PHP uses host names for sessions if you look in PHPSESSID but it
>puts the domain name in by mistake. Hence his problem.

Here's an example cookie header from PHP 4.4.4:

Set-Cookie: PHPSESSID=94c29 6afc75987991836 1534d1b89014; path=/

It doesn't set the domain; it relies on the default, correct, behaviour that
the cookie applies to the host from which it was issued.

>Now that all "domains" are being registered both with AND without the
>particular service name (WWW FTP etc) - IE as host names - this is going
>to be a big problem for PHP if it isn't sorted real soon.

No it isn't, and neither is this new.

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.

If you want to modify the properties of the session cookie for your particular
circumstances, PHP has the session_set_coo kie_params function.

--
Andy Hassall :: andy@andyh.co.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Jerry Stuckle]

Re: sessions and domain names

readmy@otherlip s.com wrote:

In article <W_GdnTmEc5nxPN _YnZ2dnUVZ_sudn Z2d@comcast.com >,
jstucklex@attgl obal.net says...
>

>>example.com and www.example.com are, by definition, two different hosts.
> The fact they resolve to the same physical server is immaterial. PHP
>>is 100% correct in its operation.
>>

>
No
>
example.com and www.example.com are the same host by both fact and hence
definition. It is the domain being addressed not necessarily a physical
machine I agree. However...
>

Actually, not. It is a common misconception. I can easily set up one
host as example.com - and it be an email server, for instance.
www.example.com could be on another machine. And ftp.example.com could,
obviously, be a third machine.

Back in the 70's and early 80's before the internet became a commodity
(and was generally known as arpanet), it was quite common to have the
email server set up as example.com. And depending on the size of the
company, you could also have ftp.example.com , gopher.example. com and others.

The fact is that using www. as a prefix to a domain in order to
address a web server on that host may not be formal syntax but it is
formal by dint of common usage. Common usage for some time has been to
address the same host in either manner. Anyone reserving a domain today
will have both assigned and resolved as the same address making them
interchangable.
>

Common usage is not the same as the RFC's. RFC's determine what is a
host and what isn't. It is quite common to have www.example.com and
example.com point to the same host. But that does not change the fact
that they identify two different hosts - which just happens to be the
same machine.

Even Apache and IIS have to be set up to handle both www.example.com and
example.com. Setting up one does NOT set up the other.

It is PHP that calls this a host and then provides 2 different answers as
to what that host is called during the same connection. The fact that it
comes up with 2 different answers to the same question during the same
connection should be telling you something?
>

It is the RFC's which call this a host. PHP is following the RFC's in
its operation.

Of course, you can always put in a request to change the RFC's.

That is a bug. And as big as a bug can get.
>
This makes PHP very much incorrect.
>
This is how the internet works. PHP needs to address this.PHP cannot
generate reliable sessions for all users until such time as this is
fixed.
>
>
In the mean time how about telling him how to avoid the bug?

Yes, this is how the internet works. And PHP is working correctly.


--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[readme@now.com]

Re: sessions and domain names

In article <ksrbk29ie6kcjo akvc5h6do93bqgd 9vsbv@4ax.com>, andy@andyh.co.u k
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, perhaps it should just use domains?



I suggest you all stop trying to disguise the massive bug in PHP

The simple fact is - If you connect to a web site PHP will generate 2
different answers to the question "what is the name of the host I am now
connected to?"

It doesnt matter how its configured or what its called - PHP should not
generate 2 sessions under any circumstances. THAT is the bug - it does -
every time the situation (which is now commonplace) occurs.

This is the reason the originator of this thread has a problem.

That is a bug. A serious bug. It isn't as mentioned by someone elsewhere
a difficult concept.

The entire and sole purpose of A session is to enable tracking of a user
during that session. PHP generates 2 sessions thereby preventing this.
PHP is broke.

You can waffle on all you like but the bug is there - its hard, its
simple to reproduce, its in every release of PHP, it causes lost data on
web sites and faults the average implementer has difficulty tracking
down, it confuses log on procedures therby reducing site security, and
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.

Stop waffling and arrange to sort it or a very public announcement will
need to be made to secure peoples web sites.

[nigel.t@by.uk]

Re: sessions and domain names

In article <JfydnfShzquN1d vYnZ2dnUVZ_qudn Z2d@comcast.com >,
jstucklex@attgl obal.net says...

Actually, not. It is a common misconception. I can easily set up one
host as example.com - and it be an email server, for instance.
www.example.com could be on another machine. And ftp.example.com could,
obviously, be a third machine.
>

The point is this is not how its done.

[Jerry Stuckle]

Re: sessions and domain names

readme@now.com wrote:

In article <ksrbk29ie6kcjo akvc5h6do93bqgd 9vsbv@4ax.com>, andy@andyh.co.u k
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, perhaps it should just use domains?
>
>
>
I suggest you all stop trying to disguise the massive bug in PHP
>
The simple fact is - If you connect to a web site PHP will generate 2
different answers to the question "what is the name of the host I am now
connected to?"
>
It doesnt matter how its configured or what its called - PHP should not
generate 2 sessions under any circumstances. THAT is the bug - it does -
every time the situation (which is now commonplace) occurs.
>

WRONG, WRONG, WRONG! These are two different hosts, and require two
different sessions.

Point me to ONE SINGLE RFC which says example.com and www.example.com
are the same host. "Common usage" does not count!

And different hosts have different sessions.

This is the reason the originator of this thread has a problem.
>
That is a bug. A serious bug. It isn't as mentioned by someone elsewhere
a difficult concept.
>

It is NOT A BUG! It is how the sessions, the HTTP protocol and the
internet itself work!

The entire and sole purpose of A session is to enable tracking of a user
during that session. PHP generates 2 sessions thereby preventing this.
PHP is broke.
>

That is one use, yes. But there are many different uses.

You can waffle on all you like but the bug is there - its hard, its
simple to reproduce, its in every release of PHP, it causes lost data on
web sites and faults the average implementer has difficulty tracking
down, it confuses log on procedures therby reducing site security, and
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.
>
Stop waffling and arrange to sort it or a very public announcement will
need to be made to secure peoples web sites.
>
>

You can complain all you want about it being a bug. But that doesn't
make it a bug. Learn how things really work. And show us exactly which
RFC is being violated by this "bug".


--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Andy Hassall]

Re: sessions and domain names

On Wed, 01 Nov 2006 11:58:31 GMT, readme@now.com wrote:

>In article <ksrbk29ie6kcjo akvc5h6do93bqgd 9vsbv@4ax.com>, andy@andyh.co.u k
>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.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Jerry Stuckle]

Re: sessions and domain names

nigel.t@by.uk wrote:

In article <JfydnfShzquN1d vYnZ2dnUVZ_qudn Z2d@comcast.com >,
jstucklex@attgl obal.net says...
>

>>Actually, not. It is a common misconception. I can easily set up one
>>host as example.com - and it be an email server, for instance.
>>www.example.com could be on another machine. And ftp.example.com could,
>>obviously, be a third machine.
>>

>
>
The point is this is not how its done.

The point is this is how the RFC's document hosts. The fact that
someone has two hosts pointing at the same machine is immaterial.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Gordon Burditt]

Re: sessions and domain names

>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, perhaps it should just use domains?
>
>
>
>I suggest you all stop trying to disguise the massive bug in PHP

Virtualhosting in Apache is not a bug.

I also dispute that the "bug" you are describing in PHP can be fixed
in PHP. It's the browser, not the server that decides what cookies
to send to the server. If the browser thinks that it's talking to
foo.com, it won't *SEND* the session cookie to www.foo.com, which
is how PHP figures out it's in the same session. Therefore it has
no idea whether it's assigning the first or the second session
cookie.

>The simple fact is - If you connect to a web site PHP will generate 2
>different answers to the question "what is the name of the host I am now
>connected to?"

On some commercial hosting sites, it will generate 100 different
answers to that question, because there are 99 customer web sites
on that same server, plus the server's own name. Yes, that site
has 100 DNS entries. And maybe even 100 *reverse* DNS entries.
Those web sites are independent and they should NOT share sessions
between different web sites on the same server. That's a security
hole. It allows one web customer to attack the site of another web
customer on the same server (not that there aren't other kinds of
security issues in this setup also).

If you really want foo.com and www.foo.com to be the same web site,
use Apache to redirect any reference to one to the other one.

>It doesnt matter how its configured or what its called - PHP should not
>generate 2 sessions under any circumstances.

It certainly should generate 2 sessions for accessing two different
web sites. Even if they have different IP addresses, that doesn't
mean it's not the same machine.

>THAT is the bug - it does -
>every time the situation (which is now commonplace) occurs.
>
>This is the reason the originator of this thread has a problem.
>
>That is a bug. A serious bug. It isn't as mentioned by someone elsewhere
>a difficult concept.
>
>The entire and sole purpose of A session is to enable tracking of a user
>during that session.

On one web site. Cookies are *NOT* intended to be able to track a
sequence of web accesses to arbitrary web sites, and neither are
sessions.

>PHP generates 2 sessions thereby preventing this.
>PHP is broke.

>You can waffle on all you like but the bug is there - its hard, its
>simple to reproduce, its in every release of PHP, it causes lost data on
>web sites and faults the average implementer has difficulty tracking
>down, it confuses log on procedures therby reducing site security, and
>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.
>
>Stop waffling and arrange to sort it or a very public announcement will
>need to be made to secure peoples web sites.

[eleven@cats.net]

Re: sessions and domain names

In article <12kiff9en9pubd @corp.supernews .com>, gordonb.m3m16@b urditt.org
says...

I also dispute that the "bug" you are describing in PHP can be fixed
in PHP. It's the browser, not the server that decides what cookies
to send to the server.
>

It is PHPSESSID that is duplicated and a variable within it that is wrong
- so you tell me what generates that ?