526462 - Java does not get cookie information from browser

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[axianx]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1) Gecko/20091029 Firefox/3.6b1 (.NET CLR 3.5.30729)

When a java applet tries to send a HTTP request the cookie information is usually picked up automatically and sent to the server as a header.
This worked in firefox 3.5 but it is broken in firefox 3.6 beta 1.
Websites which rely on cookie information for session management and use java applets won't work any more.

Reproducible: Always

Steps to Reproduce:
1. Create a Java applet that uses URLConnection to periodically connect to 
the same server as the web page that contains the applet.  Normally the 
cookie information is picked up automatically and sent to the server as a 
header.
2. Put the web page up on a server that uses sessions (or something else 
that sets a cookie).  For example, PHP with session_start().
3. Load the web page - it should work fine at first. 
4. Refresh the browser window while the applet is running.  The browser 
itself maintains the session; but on its next load the Java applet stops 
getting the cookie information and therefore loses session information.


Actual Results:  
The cookie informaton is lost in the applet HTTP request. If you use cookie based session management the webserver cannot link the applet request to the existing browser session and replies by sending a new session cookie.

Expected Results:  
At any point the Java applet should keep sending the cookie header with 
each request. The cookie contents should be consistent with the cookie information from the browser.

Comment 1

[Matthias Versen [:Matti]]

Do you use the new java plugin (npapi) with FF3.5 or the old (oji) one ?
3.6 will only use the new one AFAIK.

Comment 2

[axianx]

I tried both plugins on FF 3.5, but I can only reproduce the bug with 3.6.
You are right, 3.6 only uses the next-generation java plugin (and ignores differing settings in the java control panel).

Comment 3

[Matthias Versen [:Matti]]

Do you mean that FF3.5 on your system used the old plugin and it worked while FF3.6 is using the new NPAPI plugin and fails ?

In that case it seems to be a JRE Plugin issue, the support for the cookies got added with bug 470993 for NPAPI plugins.

Comment 4

[axianx]

I tried FF 3.5 with the old plugin and it worked.
I also tried FF 3.5 with the new NPAPI plugin and it worked too.
FF 3.6 uses the new NPAPI plugin and fails.
This is a regression bug.

I suggest to mark this bug as a blocker because proper cookie handling is essential to web applications.

Comment 5

[Johnny Stenback (:jst)]

Josh, can you debug this on Windows? If not, let me know and I'll make time to have a look. Seem like the Java plugin should get the cookie information through our _getvalueforurl(), maybe double check that it gets called and works etc first?

[e-mail] or Hao, a testcase available to Mozilla developers would be excellent here, can either of you (or anyone else) provide one? We need that to be able to confirm this bug, and block the release on it if so needed.

Also axianx, knowing what Java version you use would help ensure this is a problem in Mozilla code and not in an older version of Java. Thanks!

Comment 6

[Josh Aas]

I can take a look but we need a test case and the reporter's Java version, as mentioned in comment #5.

Comment 7

[axianx]

@Johnny: I tested firefox 3.6 beta 2 and the latest JRE 6 update 17

Comment 8

[axianx]

Attachment: Testcase (client applet and server php script)

I attached a testcase. Check README.txt for more detailed
information.
The testcase contains a tiny server script (php). I tried the testcase locally
with XAMPP (apache+php). Unfortunately I cannot provide you with a public test site.
If you need assistance using (compiling, packaging, signing..) the testcaase feel free to contact me: [e-mail]

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Blocking decision now that there's a testcase?

Comment 10

[Josh Aas]

Whatever is wrong here (if anything) doesn't seem to affect a lot of people, I don't think we need to block. We're still testing though, will change the decision if we find something bad enough.

Comment 11

[Josh Aas]

Steven's other cookie test cases are failing on Windows, I'll let him comment more but reversing decision to blocking+.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Attachment: Another testcase

Here's another testcase, which may (I hope) be easier to use.

The testcase's files need to be served from a web server that supports
PHP.  I know the copy of Apache bundled with OS X does support PHP,
but you need to edit one of its config files to turn that support on.
On the assumption that Josh (like me) is more familiar with OS X than
with other OSes, I'll make my instructions specific to OS X.  They'll
also be specific to OS X 10.5.8 -- which is where I run Apache on OS
X.  The instructions for OS X 10.6.2 (or indeed for other platforms)
are presumably not too different.

1) Edit /etc/apache2/httpd.conf to uncomment the following line:

   LoadModule php5_module        libexec/apache2/libphp5.so

2) Create a directory under /Library/WebServer/Documents to contain
   the files from session.zip -- I used "cookie".  Then unzip
   session.zip into this directory.

3) Turn on the Apache server by doing the following.  (If it's already
   running, you'll need to turn it off and on, so that it picks up the
   settings change from step 1.)

   In the Sharing pref panel check (or uncheck and check) the "Web
   Sharing" service.

   You should now be able to connect to the server locally by visiting
   'http://localhost/', or remotely by visiting
   'http://machine.your.net/'.

4) Visit 'http://localhost/cookie/session.html' (or
   'http://machine.your.net/cookie/session.html')

   After a few seconds, a Java applet will load that contains a large
   "Connect" button to the left and an empty frame to the right.

5) Click on the "Connect" button.  This makes the applet connect back
   to the server to load session.html in the empty frame.

   Now the once-empty frame will contain a page entitled "Session Test
   Page" with two more lines in it:

   The current count is 1.
   The current session id is [32-digit-hexadecimal-number].

6) Click again on the "Connect" button.

   If the applet is able to access the browser cookie store, the
   "current count" will increment to '2' and the "session id" will
   stay the same.

   If the applet is unable to access the browser cookie store, the
   "current count" will stay at '1' and the "sesion id" will change.

The PHP server (Apache) needs to store the "session id" in a browser
cookie (one whose lifetime is limited to the duration of the session).
So part of the HTTP traffic it sends to the applet tells it to create
a cookie whose "site" is "localhost" (or "machine.your.net") and whose
"name" is "PHPSESSID".  You can see this cookie by choosing "Page
Info" and clicking on the "View Cookies" button (under the "Security"
tab).

For some reason you can still "see" the cookie even if the applet
wasn't able to get the browser to create one.  But notice that its
"Content" (the session id) keeps changing every time you press the
applet's "Connect" button.

I ran my tests on Windows XP, with the current Sun Java plugin (6.0
Update 17), using today's Shiretoko (1.9.1 branch, FF 3.5.X), Namoroka
(1.9.2 branch, FF 3.6) and Minefield (trunk) nightlies.  Cookies
"worked" with Shiretoko, but not with Namoroka or Minefield.

For complicated reasons I've been unable to test on Linux.  But I
suspect this bug also exists there.  It doesn't exist on OS X (at
least using my testcase).

Comment 13

[Steven Michaud [:smichaud] (Retired)]

I'm going away for Thanksgiving.  So I'm not going to be able to work
on this bug until next week.  With luck, once I get back I'll find that
Josh has fixed it :-)

Comment 14

[Steven Michaud [:smichaud] (Retired)]

> 5) Click on the "Connect" button.  This makes the applet connect
>    back to the server to load session.html in the empty frame.

Oops.  This should read:

5) Click on the "Connect" button.  This makes the applet connect back
   to the server to load session.php in the empty frame.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

> For some reason you can still "see" the cookie even if the applet
> wasn't able to get the browser to create one.  But notice that its
> "Content" (the session id) keeps changing every time you press the
> applet's "Connect" button.

Actually, it sounds like the Java applet *does* get the browser to
create a cookie, but is unable to access/read it after it was created.

Comment 16

[Josh Aas]

I can also reproduce this now. I have Steven's test case set up on a Mac OS X web server.

Windows (7) with Java SE 6 Update 17 has the bug in Firefox 3.6b3 but not Firefox 3.5.5.

Linux (Ubuntu 9.10 64-bit) with Java SE 6 Update 15 has the bug in Firefox 3.6b3 but not Firefox 3.5.5.

Mac OS X (10.6) does not have the bug in Firefox 3.5.5 or Firefox 3.6b3.

So this is not a Windows-only problem.

Comment 17

[Josh Aas]

Attachment: fix v1.0

This is our bug, this patch fixes it. *Why* this patch fixes it I do not know yet.

The NS_FAILED check in question was always returning true, even when the call within it was returning NS_OK. With the value broken out into its own variable the problem doesn't happen.

Comment 18

[Josh Aas]

Attachment: unpatched->patched asm diff for fix v1.0

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 414423 [details] [diff] [review]
fix v1.0

The destructor for getter_Copies sets cookieStr and therefore needs to run before we test cookieStr. Without this patch, it runs after we test cookieStr.

Comment 20

[Josh Aas]

I want to get this in ASAP, filed bug 530980 for tests which I'll write soon.

Comment 21

[Josh Aas]

pushed to mozilla-central, tests are in review in bug 530980

http://hg.mozilla.org/mozilla-central/rev/d76583175408

Comment 22

[Josh Aas]

pushed to mozilla-1.9.2

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/421241c1cf28

Comment 23

[Samuel Sidler (old account; do not CC)]

These bugs landed after b4 was cut. Moving flag out.

Comment 24

[Daniel Veditz [:dveditz]]

Several comments say this bug does not affect 3.5.x -- why would this block?

Comment 25

[Josh Aas]

This does affect 3.5.x, 3.5.x users just don't use the new Java plugin by default so it usually doesn't, and no other popular plugin retrieves cookies from the browser this way (yet). If we don't fix this in 3.5.x then no pure NPAPI plugin can ever get cookies from the browser in 3.5.x.

Comment 26

[Daniel Veditz [:dveditz]]

You're saying axianx in comment 4, smichaud in comment 12, and you in comment 16, were all testing it incorrectly? What is the correct way to test? QA is going to need to know how to verify the fix if we're going to take it.

Comment 27

[Josh Aas]

What I said in comment 25 is correct. The confusion in previous testing comes from the fact that the Java plugin will attempt to use XPCOM to obtain cookies if the NPAPI option fails. NPAPI cookie retrieval is broken in 3.5 and 3.6 but the fallback Java uses works in 3.5 while it does not in 3.6 (the XPCOM option is gone in 3.6). We don't want to force plugin developers to use XPCOM to access cookies on 3.5.x, which is what we'll be doing if we don't take this patch.

I have confirmed this with Sun, NPAPI cookie retrieval fails in 3.5.x and Java has to use XPCOM.

Testing is tough because unfortunately no existing plugin depends exclusively on NPAPI to get cookies, but how could they - it is totally broken. I looked into porting my test in bug 530980 to the 1.9.1 branch but the plugin testing framework on the 1.9.1 branch is far too immature.

The good news is that the patch here is super simple (could hardly be simpler), we know it works in 3.6 and it works with the npjp2 Java plugin.

Comment 28

[Daniel Veditz [:dveditz]]

Comment on attachment 414423 [details] [diff] [review]
fix v1.0

Approved for 1.9.1.7, a=dveditz for release-drivers

Comment 29

[Josh Aas]

pushed to mozilla-1.9.1

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/7d9a70572066