HttpOnly cookies are also not given to applets even though unsigned applets have no access to the cookies that will be used.
Ditto on FreeBSD. Mozilla/5.0 (X11; U; FreeBSD i386; ja-JP; rv:188.8.131.52) Gecko/2008111515 Firefox/3.0.4
Hmm. Is the applet making HTTP requests via Necko that it doesn't associate with the page it's loaded from? If so, that's just broken (e.g. unloading the page won't stop the requests). Can you possibly point me to a testcase that shows the problem?
8 years ago
I have created a test case to show the problem: http://www.coderforlife.com/http-only-cookie-test/ It is tests both http-only and normal cookies with browser access, through AJAX, and through Java. Most browsers fail to give http-only cookies to the applet, but only Firefox and Chrome (and IE on High security) fail to give it normal cookies under some circumstances. All source code is available for the tests on that page. Necko is not being used. Only using java.io.* built-in classes to read the data. The java network messages show up in the command window with the default verbosity as: network: Connecting http://www.coderforlife.com/http-only-cookie-test/has_cookie.php with cookie "normal=xxx"
So how do I run that test? I load it, there are two buttons. Which of those is buggy, exactly? What should I be looking for? And ideal testcase here would be something that makes one and only one HTTP request, which does not get the right cookies sent in your testing, presumably, after I push a button on the page, so that I can trace that one request and see exactly what's happening...
Ah, now I see three buttons. Here's the relevant stack: #0 nsCookiePermission::GetOriginatingURI (this=0x1d3396c0, aChannel=0x0, aURI=0xb0d9317c) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/extensions/cookie/nsCookiePermission.cpp:449 #1 0x138f2ecb in nsCookieService::CheckPrefs (this=0x1d337f80, aHostURI=0x1acf88d0, aChannel=0x0, aCookieHeader=0x0) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/netwerk/cookie/src/nsCookieService.cpp:1878 #2 0x138f769c in nsCookieService::GetCookieInternal (this=0x1d337f80, aHostURI=0x1acf88d0, aChannel=0x0, aHttpBound=0, aCookie=0xb0d93538) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/netwerk/cookie/src/nsCookieService.cpp:1191 #3 0x138f813c in nsCookieService::GetCookieString (this=0x1d337f80, aHostURI=0x1acf88d0, aChannel=0x0, aCookie=0xb0d93538) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/netwerk/cookie/src/nsCookieService.cpp:686 #4 0x13450926 in nsPluginHostImpl::GetCookie (this=0x1d3b5620, inCookieURL=0x18e18e80 "http://www.coderforlife.com/http-only-cookie-test/has_cookie.php", inOutCookieBuffer=0xb0d935b8, inOutCookieSize=@0xb0d935b4) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp:6045 #5 0x188687b2 in MRJGetCookie (inCookieURL=0x18e18e80 "http://www.coderforlife.com/http-only-cookie-test/has_cookie.php", inOutCookieBuffer=0xb0d935b8, inOutCookieSize=0xb0d935b4) at /Volumes/Storage2/Developer/Mozilla/mozilla-1.6/plugin/oji/MRJCarbon/plugin/i386/../Source/MRJPlugin.cpp:254 #6 0x18a21d17 in Java_JEPCookieHandler_getCookie (env=0x18e15e60, self=0xb0d95610, url=0xb0d9560c) at /Volumes/Storage2/Developer/JavaEmbeddingPlugin/Project/JavaEmbeddingPlugin0.9.6.5/i386/../AppletView.m:346 Note that the request the cookie is for is NOT passed in to the cookie service, which makes it impossible to determine where the request is coming from. The fail-safe behavior in this case, of course, is to not hand out the cookie. I have no idea whether this is a bug in the Java Plug-in or in the plugin host. But it's certainly not a necko bug.
ah, this is coming from pluginhost... that API doesn't include any provision for passing in request info. this was one of the things that we knew would break... not much we can do here, i think, short of changing the plugin API. :(
I think we should extend the plug-in API as needed here...
This bug breaks JNLP-based applet usage when session authentication is used. 'Accept third party cookies' must be checked. Otherwise You don't get the jnlp file, instead javaws sees the login form.