Closed
Bug 477120
Opened 15 years ago
Closed 15 years ago
https cookie headers are stripped.
Categories
(MailNews Core :: Security, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 3.0b4
People
(Reporter: bugzilla, Unassigned)
References
Details
(Whiteboard: [fixed by bug 492279])
Attachments
(1 obsolete file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.3 (.NET CLR 3.5.30729) Build Identifier: Thunderbird has this odd habit of stripping cookie headers from https based content. The problem is that it prevents logging into various sites that use https (like feedburner medic feeds and https websites). Currently, the only way to get around this bug is to create a cookie via firefox and then copy it to Thunderbird. This is very advanced for most users and isn't a desirable option. Ron, the author of CS Lite, was the one who discovered this issue and shared it with me (with some details). I can supply some more details via my tests, but he would be more knowledgeable on the issue. Reproducible: Sometimes Steps to Reproduce: 1. (Optional) Install CS Lite 2. Go to https site (ThunderBrowse) or add a https feed (Feedburner) 3. Prompt to login 4. Login looks like a success, but when you go to access the content, it fails. Actual Results: Cookie headers are not sent Expected Results: Hope to be logged in via cookies from headers.
Comment 1•15 years ago
|
||
I suspect we wouldn't block Thunderbird 3 on this if it were the last bug standing, but if you (or anyone else) were interested in putting together a patch, that would be a fine thing.
Flags: wanted-thunderbird3+
Comment 2•15 years ago
|
||
My suspicion is that cookie policy wants to be modified so that it behaves differently depending on whether it's in a message or not as well as what kind of message, in a somewhat similar way to the patch in bug 374577. I expect to post a new version of that patch soon.
Component: General → Security
Product: Thunderbird → MailNews Core
QA Contact: general → security
Comment 3•15 years ago
|
||
I agree, the biggest problem here is that afaict the cookie manager in core doesn't extent like the content policy does. It is all in one which I think is why we completely override it - so expect some significant core changes, and any solution would probably help fix bug 431125 - where we have to disable some tests because of our current cookie policy. Interestingly, it seems what you suggest is what bug 374578 was originally intending on doing ("Only block remote content and cookies for content in the message pane").
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•15 years ago
|
||
Well, the work in bug 374577 is really about looking at the URI of the load and blocking based in that. It happens to use the docshell to turn off JS only because Gecko doesn't really provide a per document mechanism for that.
Comment 5•15 years ago
|
||
I am experiencing the same problems and also plead for them to be tackled. My problem description is there: http://forums.mozillazine.org/viewtopic.php?f=48&t=556097&p=5834985#p5834985. Please read at least four postings from there in order to see what is wrong with ThunderBrowse and HTTPS logins.
Comment 6•15 years ago
|
||
(In reply to comment #0) > > Thunderbird has this odd habit of stripping cookie headers from https based > content. The problem is that it prevents logging into various sites that use > https (like feedburner medic feeds and https websites). > someone on irc today in the same boat - looking to do bugzilla feed + thunderbrowse
Comment 7•15 years ago
|
||
Here's a build for folks to try (see links at bottom), two questions: 1) Does it fix this bug? 2) Does using cookies in RSS feeds still work? The background: What I've done is to change TB's cookie policy to be the same used in SeaMonkey (which is a slightly extended version of the Firefox one which includes MailNews additions). This is essentially the quick and easy, half-hour fix, if it fixes the bug and doesn't regress RSS then we can hopefully (subject to reviews) get this in for TB 3. If it doesn't fix the bug, or regresses RSS then we may not have time to get it in for TB 3. So please do try and report back. Windows and Mac builds available, based on the April 6th source code: http://s3.mozillamessaging.com/build/try-server/2009-04-06_08:40-bugzilla@standard8.plus.com-st8-cookie1/bugzilla@standard8.plus.com-st8-cookie1-mail-try-win32.installer.exe http://s3.mozillamessaging.com/build/try-server/2009-04-06_08:40-bugzilla@standard8.plus.com-st8-cookie1/bugzilla@standard8.plus.com-st8-cookie1-mail-try-mac.dmg
(In reply to comment #7) > Here's a build for folks to try (see links at bottom), two questions: > > 1) Does it fix this bug? > 2) Does using cookies in RSS feeds still work? > > The background: > > What I've done is to change TB's cookie policy to be the same used in SeaMonkey > (which is a slightly extended version of the Firefox one which includes > MailNews additions). > > This is essentially the quick and easy, half-hour fix, if it fixes the bug and > doesn't regress RSS then we can hopefully (subject to reviews) get this in for > TB 3. If it doesn't fix the bug, or regresses RSS then we may not have time to > get it in for TB 3. > > So please do try and report back. > > Windows and Mac builds available, based on the April 6th source code: > > http://s3.mozillamessaging.com/build/try-server/2009-04-06_08:40-bugzilla@standard8.plus.com-st8-cookie1/bugzilla@standard8.plus.com-st8-cookie1-mail-try-win32.installer.exe > http://s3.mozillamessaging.com/build/try-server/2009-04-06_08:40-bugzilla@standard8.plus.com-st8-cookie1/bugzilla@standard8.plus.com-st8-cookie1-mail-try-mac.dmg (In reply to comment #7) > Here's a build for folks to try (see links at bottom), two questions: > > 1) Does it fix this bug? > 2) Does using cookies in RSS feeds still work? > Okay, I can confirm it works with my dev build (this is with ThunderBrowse's cookies file disabled [Read the "How to test with ThunderBrowse"]). It looks like it fixes this bug (there are some sites that I now know won't work with ThunderBrowse [that I could have never known before [one being wegame.com]]). I haven't tried an RSS feed yet. But from the current results it looks like it will. ==Site tests== I can login to several websites that previously were not allowed. Here are the sites that I tested that previously didn't work and their status (all https): mail.google.com (in fact all of google): PASSED netvibes.com: PASSED (couldn't login in 2.0.0.19 because it uses https cookies to auth and stalled before) youtube.com (actually took the google auth cookie): PASSED twitter.com: PASSED bugzilla.mozilla.org: PASSED (writing this within ThunderBrowse [however see note]) I'll test more sites soon. ==How to test with ThunderBrowse== You need to edit two files if you are currently using 3.2.3. tbinit.js and accessbrowser.xul (This bug has been marked for fix in 3.2.4 [using dev build right now]) In accessbrowser.xul delete the line linking to tbcookies.js In tbinit.js comment lines 133, 327 and 328 Then open about:config and change these prefs: network.cookie.alwaysAcceptSessionCookies true network.cookie.disableCookieForMailNews false Restart your client and you will be able to login successfully. ==bugzilla note== I don't know if this shows up in fx as well, but I can't post comments on this bug. I get a bugzilla error telling me that the flag status is not valid.
Bugzilla note only applies to ThunderBrowse (I traced the issue down and filed a bug report).
Comment 10•15 years ago
|
||
Yesterday I also tested the dev build with the current ThunderBrowse version (fixes as mentioned above not applied). I also succeeded with Google, but failed with e.g. XING (Germany's most popular LinkedIn-like business network) as well as a banking site (dresdner-privat.de). I guess XING uses cookies for auto-login, but the banking site does not, so the latter might be a JavaScript problem rather than a cookie issue (I had also installed the CS Lite add-on). XING also told me that I should activate JS, and the login button does not work. I can only report this from a user point of viw, because I am not an add-on developer.
Comment 11•15 years ago
|
||
One more question: If this is a quick-fix and proves to solve the problem reliably, would it be asking too much to port it back to Thunderbird 2? TB3 is not due to be released for quite a while, I suppose.
Comment 12•15 years ago
|
||
Thanks for the testing folks, I'll read through the comments later, though the RSS cookie question is still open. (In reply to comment #11) > One more question: If this is a quick-fix and proves to solve the problem > reliably, would it be asking too much to port it back to Thunderbird 2? TB3 is > not due to be released for quite a while, I suppose. TB 3 is looking to be around June time, so not that far away. We probably wouldn't back-port as we'd need to do a full study (due to the risks) which I think wouldn't be worth it.
Reporter | ||
Comment 13•15 years ago
|
||
Yes, I noticed XING doesn't work (it acts like it's not submitting but it is [I don't know exactly what is causing it as I've haven't tested enough]). It shows that I have js enabled (maybe I'm missing something [I'm also using the newer 3.2.4 [the one I just uploaded again like 10 seconds ago]]). Also: paypal.com works fine here. I was able to login okay and manage transfers. I think this patch fixes the bug just fine but I'll continue to test.
Comment 14•15 years ago
|
||
This is the patch that I put on the try server builds - basically it removes the Thunderbird specific cookie policy and relies on the core policy. I did take a brief look to see if cookies would work as expected with rss and other things, but ended up getting too confused as to what exactly was going on, and I haven't got time at the moment to take this any further. To take this patch, I think we'd want to see a set of cases where the cookies were accepted and blocked as we would expect them to be. Preferably these would be automated tests using the http server, or possibly unit tests - there are already some examples about (some of which TB disables due to the current policy set up, see bug 431125).
Reporter | ||
Comment 15•15 years ago
|
||
(In reply to comment #14) > Created an attachment (id=375169) [details] > Potential base patch > > This is the patch that I put on the try server builds - basically it removes > the Thunderbird specific cookie policy and relies on the core policy. > > I did take a brief look to see if cookies would work as expected with rss and > other things, but ended up getting too confused as to what exactly was going > on, and I haven't got time at the moment to take this any further. > > To take this patch, I think we'd want to see a set of cases where the cookies > were accepted and blocked as we would expect them to be. Preferably these would > be automated tests using the http server, or possibly unit tests - there are > already some examples about (some of which TB disables due to the current > policy set up, see bug 431125). What do you need us/me/whoever to do to get this thing pushed to release?
Comment 16•15 years ago
|
||
(In reply to comment #15) > What do you need us/me/whoever to do to get this thing pushed to release? I've moved most of this work out to bug 492279 - that bug is now blocking TB 3. I'll document there what I need to do in a few mins.
Updated•15 years ago
|
Attachment #375169 -
Attachment is obsolete: true
Updated•15 years ago
|
Comment 17•15 years ago
|
||
For anyone not following bug 492279 this should be fixed when using Thunderbrowse or looking at content in windows that aren't the main Thunderbird window, i.e. open in new window in Thunderbrowse. Using cookies when browsing content within the main Thunderbird window will require bug 501925 to be fixed (which we are currently looking at).
Depends on: 501925
Comment 18•15 years ago
|
||
I believe Bug 492279 has now fixed this bug. The complete fixes should be in tomorrow's TB 3 nightlies.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 492279]
Target Milestone: --- → Thunderbird 3.0b4
Reporter | ||
Comment 19•15 years ago
|
||
(In reply to comment #18) > I believe Bug 492279 has now fixed this bug. The complete fixes should be in > tomorrow's TB 3 nightlies. Awesome. I'm gonna post something on the blog informing my users.
You need to log in
before you can comment on or make changes to this bug.
Description
•