165685 - When switching from no cookiepath to using cookiepath, old cookie gets in the way

Status: RESOLVED DUPLICATE of bug 121419

(Bugzilla :: Bugzilla-General, defect)

Description

[Joel Peshkin]

In experimenting with using cookiepath (yeah - I had been leaving it defaulted),
it seems that the leftover cookie with path="/" from before I set the cookiepath
would supercede the more specific cookie with the new cookiepath.  (This occurs
with Mozilla 1.0)  As a result, as long as cookiepath remains set to something
more specific than "/", users must log in again on every page.

In any site where the cookiepath was set to "/" or where 2.14 was previosuly
used, I expect that this would be an issue on each client machine.

Probably the right thing to do, when cookiepath is enabled is to force the old
cookies out with something like...

print "Set-Cookie: Bugzilla_login= ; path=/; expires=Sun, 30-Jun-80 00:00:00 GMT
Set-Cookie: Bugzilla_logincookie= ; path=/; expires=Sun, 30-Jun-80 00:00:00 GMT

This is likely related to bug 121419, but the FQDN issue is moot because it is 2
URLs on the same server.

Comment 1

[Bradley Baetz (:bbaetz)]

Yeah, I noticed this too. I thikn that this is a mozilla bug - rfc2109 says:

"If multiple cookies satisfy the criteria above, they are ordered in the Cookie
header such that those with more specific Path attributes precede those with
less specific. Ordering with respect to other attributes (e.g., Domain) is
unspecified."

Comment 2

[Bradley Baetz (:bbaetz)]

Actually, this is a bz bug. The $::COOKIE stuff in CGI.pl needs to consider the
most specific path attribute, ie the first one, not the last//

CGI::Cookie claims that this is a netscape bug, but the specs agree that this
behaviour is correct.

Comment 3

[Joel Peshkin]

Attachment: Interim patch to clobber cookie with old default path (see comment)

This patch just clears out the old default cookie if cookiepath is something
more than "/"

 This should help sites that have   http://myserver/thiszilla/	 and
http://myserver/thatzilla/, but we should do as bbaetz suggests otherwise sites
that have http://myserver/thiszilla/ and http://myserver/thiszilla/thatzilla/
would not be fixed.

Comment 4

[Joel Peshkin]

It appears from the CGI.pm docs that the browser may not even tell the server
which of several matching cookies was hit.

So, the proper fix may actually be to change cookiepath to cookiesuffix and
change the name of the cookie instead of its path.

Comment 5

[Jacob Steenhagen]

I think what our problem is would be that the browser is sending them in the
order of:
bugzilla.domain.org/bugzilla
bugzilla.domain.org/
.domain.org/bugzilla
.domain.org/

And when we assign them $::COOKIE (using our own code, not CGI.pm) we just keep
clobbering the old value and $::COOKIE{Bugzilla_login} ends up being the one
sent for .domain.org (the last, or least significant one).  We need to either
test all the cookies sent to us or modify the code so it picks the most
significant cookie.

The problem I see with the patch supplied here is that if I have:
/bz123
/bz456
/bz789
/bz147
/bz258
/bz369
(such as on landfill) on only /bz147 uses a seperate database, then I could set
the cookie path all the other installs to be / and they'd share one login and
set /bz147 to be "/bz147" and if the code behaved properly it'd use it's own
login and everybody would be happy :), with this patch, logging in at /bz147
would clobber the login for all the other installs (I know that's what the
pre-cookiepath behavior was, but improvment is good, esp. for landfill testing :)

Comment 6

[Joel Peshkin]

Jake is correct, and that makes this a dupe of 121419


*** This bug has been marked as a duplicate of 121419 ***