2.82 KB, application/zip
2.75 KB, application/zip
1.03 KB, patch
|Details | Diff | Splinter Review|
7.83 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:184.108.40.206) 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.
Version: unspecified → 3.6 Branch
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.
Severity: critical → normal
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: 3.6 Branch → 1.9.2 Branch
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).
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.
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.
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? firstname.lastname@example.org 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!
Assignee: nobody → joshmoz
I can take a look but we need a test case and the reporter's Java version, as mentioned in comment #5.
@Johnny: I tested firefox 3.6 beta 2 and the latest JRE 6 update 17
Created attachment 411936 [details] 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: email@example.com
Blocking decision now that there's a testcase?
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Flags: blocking1.9.2? → blocking1.9.2-
Steven's other cookie test cases are failing on Windows, I'll let him comment more but reversing decision to blocking+.
Flags: blocking1.9.2- → blocking1.9.2+
Created attachment 414342 [details] 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).
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 :-)
> 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.
> 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.
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.
OS: Windows XP → All
Hardware: x86 → All
Created attachment 414423 [details] [diff] [review] 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.
Attachment #414430 - Attachment description: patched->unpatched asm diff for fix v1.0 → unpatched->patched asm diff for fix v1.0
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.
Attachment #414423 - Flags: review?(roc) → review+
I want to get this in ASAP, filed bug 530980 for tests which I'll write soon.
pushed to mozilla-central, tests are in review in bug 530980 http://hg.mozilla.org/mozilla-central/rev/d76583175408
pushed to mozilla-1.9.2 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/421241c1cf28
status1.9.2: --- → final-fixed
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Attachment #414423 - Flags: approval220.127.116.11? → approval18.104.22.168?
These bugs landed after b4 was cut. Moving flag out.
status1.9.2: beta4-fixed → final-fixed
Several comments say this bug does not affect 3.5.x -- why would this block?
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.
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.
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 on attachment 414423 [details] [diff] [review] fix v1.0 Approved for 22.214.171.124, a=dveditz for release-drivers
Attachment #414423 - Flags: approval126.96.36.199? → approval188.8.131.52+
pushed to mozilla-1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/7d9a70572066
status1.9.1: wanted → .7-fixed
You need to log in before you can comment on or make changes to this bug.