133496 - Cookies, javascript and "Enable cookies for the originating web site only" setting

Status: VERIFIED FIXED

(Core :: Networking: Cookies, defect)

Description

[Juha Luoma]

I use a website that requires authentication. After succesfull authentication
authentication info is stored in a cookie. This cookie is then sent along with
every request to that site IF I use "Enable all cookies" setting. IF I use
"Enable cookies for the originating web site only" setting, the cookie is not
sent with request that originate from Javascript. This particular site preloads
some images for example with Javascript. Loading these images fails when "Enable
cookies for the originating web site only" setting is selected because
authentication cookie is not sent with requests generated with Javascript. I
verified this with packet capture, but unfortunately I do not have it available
right now. For other elements authentication cookie is sent correctly. This
started bugging me around 0.9.9.

Comment 1

[Stephen P. Morse]

If the images that you are loading are not on the same server as the page that 
the user requested, then this is indeed correct behavior.  Let me give you some 
background here.

First off, n6 and n4 behave a bit different with regard to 
"originating-server-only" cookies.  In n4, that choice controlled only the 
setting of cookies whereas in n6 is controls both the setting of cookies and the 
sending of cookies.  In essense we deemed that the n4 behavior was incorrect 
(violated user's privacy) and therefore we corrected it in n6.  That would 
explain why your test would have sent out the cookies in n4 but not in n6.

Second, detection of the originating server was broken in n6 for the longest 
time and only recently got fixed.  The checkin that fixed that was bug 107579 
and bug 87388.  Prior to this fix, the "originating-server-only" choice was 
really having no effect.  That is why your cookies were being sent to the images 
previously and only started "bugging" you around 0.9.9.

Therefore closing this out as invalid.  If you can show me that the images are 
indeed from the originating server, then reopen the report.

Comment 2

[Juha Luoma]

The images are from the originating server. I'll attach a network capture and
explanation that shows what's going on.

Comment 3

[Juha Luoma]

Attachment: Network data capture, read with Ethereal for example.

The attachemnt shows 5 selected data frames from network between Mozilla
browser (172.16.57.46)and Squid proxy on port 8000 (172.16.49.140). This shows
the problem.

First two frames are from the login phase that sets the AuthCookie. 

3rd and 4th frames are normal http requests. First is from redirection in login
phase and second is a image element on that page. Note that AuthCookie is sent
along with the request correctly. 

5th frame shows the problem. There Mozilla tries to fetch a image from the same
server but AuthCookie is not sent with the request. This request is generated
by a piece of Javascript that preloads some images for the user to able to
select image he wants from the pulldown menu. All this Javascript is embedded
in html, so even it is from the same server.

Comment 4

[Stephen P. Morse]

So the problem occurs when the image is loaded from js, is that correct?  Can 
you attach a reduced version of that js code.

Here's a summary of the traffic you posted.

frame 1: HTTP request that sends the following cookies:
   Apache
   AuthCookie
   last_login

frame 2: HTTP response that sets the following cookies:
   AuthCookie
   last_login

frame 3: HTTP request that sends the following cookies:
   Apache
   Robinson
   2002iro
   iro3350
   AuthCookie
   last_login

frame 4: HTTP request that sends the following cookies:
   Apache
   AuthCookie
   last_login

How were the cookies Robinson, 2002iro, and iro3350 set?  Was that done by 
javascript after frame 2 arrived?  And, similarly, did they get unset by 
javascript as well?

Comment 5

[Juha Luoma]

Yes, this is my understanding. I'm not familar with js, I'll attach the page as
a whole.

The other cookies Robinson, 2002iro, and iro3350 are permanent cookies from that
same site with path restirction /doc. I see those in my cookie manager. I don't
know when they were set, at least not during login or after that (I searched the
whole traffic dump from login to the point of the problem).

Comment 6

[Juha Luoma]

Attachment: Page with the problem

This is slightly reduced (some unnecessary html stripped) page on which the
problem appears. The js function preLoad tries to load the images but
authentication cookie is not sent with these requests so images can not be
loaded and the page does not show the images that it should.

Comment 7

[Stephen P. Morse]

OK, now that you tell me that those extra cookies have path restrictions, it's 
clear why they are sent out only in that one frame.  I didn't realize that they 
had a path attribute and so was puzzled why they appeared only in that one 
place.

Comment 8

[Juha Luoma]

The fix to the bug 134203 didn't fix this one (tested with build 2002040903).

Comment 9

[Stephen P. Morse]

Although the symptoms are different, the patch just posted to bug 137079 will 
probably fix this bug as well.  Can someone who can reproduce this bug please 
apply that patch and see if it takes care of this problem.

Comment 10

[Peter Trudelle]

Nav triage team needs info: Does this happen on any top sites? What is the
impact on target users?

Comment 11

[Stephen P. Morse]

The impact of this one instance is small.  But see the discussion in bug 137079.  
Although the symptoms there are different, the fix for that bug will fix many 
other bugs as well, this probably being one of them.

Comment 12

[Juha Luoma]

This is now fixed in trunk build 2002051408! Great stuff, thanks morse! The web
site in this bug works now also with "Enable cookies for the originating web
site only" setting. This is quite popular financial site here in Finland.

Comment 13

[Stephen P. Morse]

Not fixed on branch.

Comment 14

[Stephen P. Morse]

Being marked fixed since the patch for 137079 is checked in on trunk.  However 
it is not yet fixed on the branch.

Comment 15

[Tom Everingham]

marking verified per reporters comments

verified branch - 05/28/02 linux rh6, mac osX, winNT4