510307 - Cookies for .domain.com not recognized for www.domain.com

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Bozhidar Bozhanov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

When a cookie for ".domain.com" is set, and the user opens www.domain.com, the cookie is not regognized as being from that domain. Actually, the cookie for 'domain.com' has 'host' in the cookie preview, while the '.domain.com' has 'domain' instead of 'host'. 
In previous versions this was working fine.

Reproducible: Always

Steps to Reproduce:
1. Open http://somedomain.com
2. Login (i.e. set a cookie for '.somedomain.com')
3. Nagivate to http://www.somedomain.com
Actual Results:  
the cookie is not recognized, and you are not logged in. As if these are two different pages.

Expected Results:  
The user should appear to be logged (i.e. the cookie recognized as belonging to that domain)

Comment 1

[Jo Hermans]

That depends on the actual website, in particular the 'domain' parameter in the Set-Cookie or Set-Cookie2 header that is setting the cookie. The default www.somedomain.com would be readable on the .somedomain.com level, but the reverse is not true. See RFC 2965 : pay partiulcr attention to section 3.2.2

Also, it's important to know which top-level domain is used (.com ?) - a TLD isn't always the last word (for instance in case of www.somedomain.co.uk it's .co.uk).

Comment 2

[Bozhidar Bozhanov]

The domain in my specific case is ".nl"
The fact I reported it as a bug immediately after I saw it, was because I'm the developer of the site, and I made it work fine around 2-3 weeks ago - on FF, IE, Opera and Chrome. And it worked in all browsers. Now after the last (or the one before it) update, FireFox is the only of the 4 that behaves not the way it is expected.
I checked on my FireFox 2 on my old laptop - it is fine there, too.
The site in question is "bedrukt.nl". Try logging in with testtest / testtest on https://bedrukt.nl/inloggen.jsp , and then add "www" to the URL. The cookie in question is the session cookie (JSESSIONID)

Comment 3

[Jo Hermans]

You're using a header like this (on https://bedrukt.nl/inloggen.jsp) :

Set-Cookie: JSESSIONID=F33F9B6D42E07C3E72E985E7836CAC0B; Path=/

There's no domain parameter, so it defaults to bedrukt.nl. Because there is no dot at the beginning of effective request-host, the default domain can only domain-match itself (RFC 2965, section 3.3.1)

I think it would have worked if you used .bedrukt.nl as the domain parameter, like explained in bug 465507. I'm not sure why it stopped working in the update, maybe because of bug 421494.

Note that www.bedrukt.nl is a *different* site than bedrukt.nl, despite any possible CNAME redirect.

Comment 4

[Bozhidar Bozhanov]

Yes, www.bedrukt.nl and bedrukt.nl are different sites, that's why on login I'm explicitely getting the existing JSESSIONID cookie and set its domain to ".bedrukt.nl", and send it to response. I will further investigate my code, but my suspicion about this thing working in previous versions, and in other browsers, is still lurking. :)

Comment 5

[Bozhidar Bozhanov]

Hmm, the problem is not what I initially thought, so you I'm marking it resolved.
The real issue was that there were two JSESSIONID cookies persisting (and probably because of the session manager they wouldn't go away even though they are to expire when the browser if closed). I removed all the cookies manually, reattempted login, and it worked.