User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:22.214.171.124) Gecko/2008121623 Ubuntu/8.10 (intrepid) Firefox/3.0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2a1pre) Gecko/20090125 Minefield/3.2a1pre When third-party cookies are disabled, live bookmarks fail to authenticate by cookies, even on the same domain. Reproducible: Always Steps to Reproduce: 0. Disable third-party cookies in preferences > privacy by unchecking the "accept third-party cookies" button. 1. Find a feed that requires cookie authentication, i.e wikipedia watchlist: http://en.wikipedia.org/w/api.php?action=feedwatchlist 2. Open the feed as a web page. Check you are logged in and add it as a live bookmark. 3. Check live bookmark contents. Actual Results: On wikipedia, you will get a unique element "Error (wlnotloggedin)", but not watchlist content. Expected Results: Watchlist content displayed without authentication error. To confirm that you are still logged-in, you can re-enable third-party cookies and then refresh live bookmark. Also, reloading the feed displayed as webpage demonstrates that your are still logged-in. I could confirm with LiveHTTPHeaders <http://livehttpheaders.mozdev.org/> extension that the problem comes from cookies. A cookie is always sent when third-party cookies are allowed. A cookie is always sent when the feed is opened as a webpage. Cookie is NOT sent when third-party cookies are disabled AND live bookmark is reloaded. If your wikipedia watchlist is empty, you can watch the page http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28miscellaneous%29 (click on the "watch" tab button) which is frequently updated. This allows you to clearly see whether your watchlist is displayed or not. This bug was seen on a Windows XP i686 platform with Firefox 3.0.5; on Ubuntu 8.10 x64 with Firefox 3.0.5; and with latest-trunk Linux i686 nightly. This could be a security issue for some people. See http://getsatisfaction.com/twitter/topics/how_do_i_use_firefoxs_live_bookmarks_with_twitter for an example where password was sent visible (along with the URL).
Should be pretty easy to fix. In nsLivemarkService.js, the LS__updateLivemarkChildren function just needs to QI httpChannel to nsIHttpChannelInternal, and set forceAllowThirdPartyCookie.
I can confirm this problem with Firefox 3.5.9 on Fedora 12. Problem occurs with Livejournal rss-bookmarks, and disappears when ticking "accept 3rd party cookies". Probably just a problem in the live bookmark logic; live bookmark URL's are not a third party.
(In reply to comment #3) > I can confirm this problem with Firefox 3.5.9 on Fedora 12. Problem occurs with > Livejournal rss-bookmarks, and disappears when ticking "accept 3rd party > cookies". Probably just a problem in the live bookmark logic; live bookmark > URL's are not a third party. Yes; see comment 2 where I state what the fix likely is. Someone just needs to come along with a patch and a test.
No longer reproducible on Mozilla/5.0 (X11; Linux i686; en-US; rv:2.0b2pre) Gecko/20100708 Minefield/4.0b2pre. It seems that livemark no longer depends on cookies. I guess we can close this bug now.
Maybe it was fixed with bug 437174? In this case it was a duplicate.
Unfortunately, this bug still has not been fixed with Firefox 4.0.1 (firefox-4.0.1-2.fc15.x86_64). The LiveJournal RSS live bookmark still shows no entries when the "disable third party cookies" is checked.
(In reply to Xavier Robin from comment #6) > Maybe it was fixed with bug 437174? In this case it was a duplicate. Given bug #437174 was fixed, and my situation still has not changed in Firefox 7, I take it this bug is not actually a duplicate of #437174 . Could somebody please re-open this bug report?