475238 - Disabling third-party cookies also prevents cookies being sent by Live bookmarks

Status: RESOLVED DUPLICATE of bug 437174

(Firefox :: Bookmarks & History, defect)

Description

[Xavier Robin]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.5) 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).

Comment 2

[Shawn Wilsher :sdwilsh]

Should be pretty easy to fix.  In nsLivemarkService.js, the LS__updateLivemarkChildren function just needs to QI httpChannel to nsIHttpChannelInternal, and set forceAllowThirdPartyCookie.

Comment 3

[RSpliet]

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.

Comment 4

[Shawn Wilsher :sdwilsh]

(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.

Comment 5

[Luyun Xie]

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.

Comment 6

[Xavier Robin]

Maybe it was fixed with bug 437174? In this case it was a duplicate.

Comment 8

[RSpliet]

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.

Comment 9

[RSpliet]

(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?