211472 - ica.se claims I don't allow cookies (checks via document.cookie)

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: Other, defect)

Description

[André Dahlqvist]

[Tested with a Mozilla build from 2003-07-02 on Linux]

This cookie bug appears to be Linux-only: doron said to me on IRC that he could
reproduce it in Linux, but not in Windows.

Steps to reproduce:

1) Go to http://www.ica.se/
2) Click on "Logga in" in the top left corner of the screen.

Result:
You are greeted with a JavaScript message saying "Du måste tillåta cookies för
att kunna logga in" (meaning "You have to allow cookies to log in").

Expected result:
Show a form that allows me to log in.

Workaround is to go directly to
https://www.ica.se/FrontServlet?state=loginpop&target=mina_sidor

I first suspected a website problem, so I looked at their code. When you click
on "Logga in" this code is executed:

if(checkCookies())
Launch(260,123,'https://www.ica.se/FrontServlet?state=loginpop&target=mina_sidor'+param);

The javascript function checkCookies() (located in
http://www.ica.se/admin/js/common.js) looks like this:

function checkCookies(){
    if(document.cookie)
            return true
    else{
            alert('Du måste tillåta cookies för att kunna logga in');
            return false;
    }
}

Apparently, semicolons are optional in JS, so that's not the bug.
This function is for some reason also duplicated in another part of common.js,
but I don't know if that can cause the described problem.

Comment 1

[André Dahlqvist]

It should be obvious by the fact that I report this as a bug, but just to be
super-clear:

I do have Mozilla set to allow cookies. I tried changing from the default
"Enable cookies based on privacy settings" to "Allow all cookies", but the
result was the same. I have not changed the settings that allow reading or
changing cookies via javascript, so that's not the problem either.

Comment 2

[[e-mail]]

Can you show the js code the site uses to set the cookie, before it tries to
read document.cookie?

Comment 3

[André Dahlqvist]

Dan, I will try to find that for you.

Two important observations:

o This bug DOES happen on both Windows and Linux, so not platform parity.
o More importantly, this worked on Mozilla 1.3a but broke on Mozilla 1.3b

In other words, it broke between december 13, 2002 and February 10, 2003. There
were a lot of cookie related checkins between these dates, so it will take a
while to narrow it down further.

Adding 'regression' keyword.

Comment 4

[André Dahlqvist]

Ok, I got it narrowed down.

Build from 2003-01-20 works
Build from 2003-01-22 does not work

If I back out the below change on a tree from 2003-01-22, it works again:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=01%2F21%2F2003+05%3A26&maxdate=01%2F21%2F2003+05%3A26&cvsroot=%2Fcvsroot

Comment 5

[[e-mail]]

Okay - so it's something to do with the expiry date of the cookie. However, we
still need to know exactly what cookie the site is trying to set, to determine
if it's a site problem or not. ;)

Comment 6

[André Dahlqvist]

According to below sniffing of www.ica.org they send this in the HTTP header:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

http://www.samspade.org/t/safe?u=http%3A%2F%2Fwww.ica.se%2FFrontServlet%3Fstate%3Dstart%26event%3Dload_top%23

Comment 7

[[e-mail]]

that's a cache-control header, nothing to do with cookies. the set-cookie header is

Set-Cookie: portal_webstat=JFZQ1EKV5QOYNV30LOA4RZY;Max-Age=-1;Domain=.ica.se;Path=/

so they set a cookie with max-age of -1, which will delete any existing cookie
and not be set. I doubt this is the culprit - they probably try to set another
cookie somewhere, which is failing.

Comment 8

[[e-mail]]

The site violates spec and should fix their code. See cookie log below - they
try to set three cookies with negative max-ages, which we don't set, in
accordance with spec. The fix, in their case, would be to not specify any
max-age header and just let the cookie default to a session cookie.

André, would you be interested in contacting the site to get them to change
this? If so, we can reassign the bug to you as evangelism.

===== COOKIE NOT ACCEPTED =====
request URL: http://www.ica.se/FrontServlet
cookie string:
portal_webstat=FKIBGHN4DNDWIGXGFV5ZTXI;Max-Age=-1;Domain=.ica.se;Path=/
current time: Thu Jul 03 18:46:58 2003 GMT
rejected because cookie has already expired

===== COOKIE NOT ACCEPTED =====
request URL: http://www.ica.se/FrontServlet?state=start&event=load_top
cookie string:
portal_webstat=EQGRISHBYOX0OD1UQEZ3CUA;Max-Age=-1;Domain=.ica.se;Path=/
current time: Thu Jul 03 18:46:58 2003 GMT
rejected because cookie has already expired

===== COOKIE NOT ACCEPTED =====
request URL: http://www.ica.se/FrontServlet?s=ica&state=start&event=load_content
cookie string:
portal_webstat=XES2ITL2EIB1N2CEBTWUVRI;Max-Age=-1;Domain=.ica.se;Path=/
current time: Thu Jul 03 18:46:59 2003 GMT
rejected because cookie has already expired

Comment 9

[André Dahlqvist]

Sure. Taking.

Comment 10

[[e-mail]]

Thanks! Since you're taking this, the relevant part of the spec can be found at
the following link, on page 5:

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html

Max-Age=delta-seconds
Optional. The Max-Age attribute defines the lifetime of the cookie, in seconds.
The delta-seconds value is a decimal non- negative integer. After delta-seconds
seconds elapse, the client should discard the cookie. A value of zero means the
cookie should be discarded immediately.

and omitting the max-age and expires headers will just make it a session cookie,
which will work just fine here.

Comment 11

[Per Ångström]

Removing "regression" keyword.

Comment 12

[André Dahlqvist]

Fixed.

Comment 13

[benc]

Is this fixed, like the site is fixed or fixed like it works now?

Comment 14

[André Dahlqvist]

I asked the site to fix it so that they followed the cookie specification and
specify a non-empty Path.