Closed Bug 1322113 Opened 8 years ago Closed 5 years ago

WebExtensions request does not contain cookies even for visited sites when 'from visited' setting is enabled, in Private Browsing mode

Categories

(Core :: Networking: Cookies, defect, P2)

Product:
Core
Component:
Networking: Cookies
Version:
53 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla74
Tracking Flags:
Tracking Status
firefox51 --- wontfix
firefox52 --- wontfix
firefox-esr68 --- wontfix
firefox53 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- fixed

People

(Reporter: arz.giyan, Assigned: ehsan.akhgari)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [necko-triaged] triaged)

Attachments

(3 files)

test_ext.zip
(deleted), application/x-zip-compressed
Details
cookieBehavior
(deleted), patch
Details | Diff | Splinter Review
Bug 1322113 - Fix the implementation of the 'from visited' cookie policy in private browsing mode;
(deleted), text/x-phabricator-request
Details
Attached file test_ext.zip (deleted) —
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Build ID: 20161201172143 Steps to reproduce: - enable 'Always use private browsing mode' + 'Accept third-party cookies: from visited' - load attached extension - click browser action, it will take you to httpbin. Click again while you are on httpbin. Actual results: Cookie is not appended to requests from any WebExtension context (page/popup/background). Cookie is there if you visit https://httpbin.org/cookies manually. Cookie is appended if you select 'Accept third-party cookies: always' Expected results: Extension requests to page should contain cookies if they exist for this domain and page was visited.
Version: 51 Branch → 53 Branch
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
:kmag(In reply to Kris Maglione [:kmag] from comment #1) > > *** This bug has been marked as a duplicate of bug 1319536 *** I can still repro this bug in 53.0a1 (Win64 53.0.0.6198) with original scenario ('Only visited' option prevents cookies from being attached to background requests). Do I need to provide more details?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Assignee: nobody → mixedpuppy
Priority: -- → P2
Whiteboard: triaged
I've confirmed that this report is still reproducible. The test in bug 1319536 doesn't cover the 'Accept third-party cookies: from visited' use case. As well, when third party cookies is set to always, fetch is working but xhr does not work in some of the code paths in the test addon. Kris, thoughts on these two issues?
Flags: needinfo?(kmaglione+bmo)
Attached patch cookieBehavior (deleted) — — Splinter Review
Patch to introduce test for 'Accept third-party cookies: from visited'
There are some more limitations * see bug 1295660 for referrer and origin header limitations of content-script XHR/fetch. * background page XHR/fetch has no way to deal with containers or other origin attributes, only content scripts get the right principals, which requires a tab to be opened * patching of the xray-wrappers[0] for xhr/fetch makes it difficult to access the page instances instead of the sandbox ones [0] http://searchfox.org/mozilla-central/rev/30fcf167af036aeddf322de44a2fadd370acfd2f/toolkit/components/extensions/ExtensionContent.jsm#384-386
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1295660
I am also getting this issue under similar circumstances. I have third party cookies set to "never", and a WebExtension that has permissions set for the target origin. When making fetch(targeturl, { mode: "cors", credentials: "include" }) requests from a background script however, only a session cookie is applied to the request, not the remaining cookies containing the auth tokens. It works fine when visiting the page in a browser tab. This happens to me when making requests to addons.mozilla.org, where the auth token cookie is also for addons.mozilla.org. Let me know if this is better suited for a separate bug, but it seems there are a few cases regarding cookie settings that fit together well so I'm just leaving a comment for now.
This breaks SDK add-ons using Downloads.jsm as well.
51 and 52 are affected too.
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
While I see the behavior from comment 5, I don't think they apply to the specific test in this bug (ie. the test addon attached by OP). In this case, the origin/referrer have no affect as the test site just reflects those. The issue is solely the cookie setting all vs. visited, where no cookies are sent if the preference is visited. I also dont think this is a webextension bug, it feels lower level, perhaps something on the channel where cookies are added to the request.
(In reply to Shane Caraveo (:mixedpuppy) from comment #9) > I also dont think this is a webextension bug, it feels lower level, perhaps > something on the channel where cookies are added to the request. Who can investigate this? It looks like I would really like to set my third party cookie settings back to "Never", where this bug also occurs. Looking at current P1's it seems Kris already has a pretty full plate, and if this is a platform bug maybe we can get some help from other teams.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Looking at bug 674397 which I randomly found the platform behavior is probably correct, but WebExtensions with sufficient permissions should be able to get around this limitation.
I don't think webextensions should work around how the platform is supposed to work for cookies without the proper justification for that. I would like clarification on whether "from visited" is working correctly. Assuming it is, then we need to decide if webextensions should behave differently. In any case, I think that is still going to be platform changes, not something in the webextensions layer.
My SDK add-on strips credentials in XHRs to addons.mozilla.org if "from visited" is set, even though I obviously visit that website a lot.
Shouldn't we move this to Core XHR if it can only be fixed there?
webextensions: --- → ?
webextensions: ? → +
Mass wontfix for bugs affecting firefox 52.
status-firefox52: affected → wontfix
I've been trying to see if this bug can be fixed soon, but I understand there are other priorities based on affected add-ons. To workaround this bug, user may add the target host in the cookie exception list, which set Firefox to always allow the cookies from the said origin.
> I don't think webextensions should work around how the platform is supposed to work for cookies without the proper justification for that. I can respect this position, but as an extension developer it is problematic. If the purpose of WebExtensions is, in part, to make seamless development of extensions that work across browsers, then this is basically an achilles heel for a lot of website-specific extensions. Chrome behaves this way and has drastically more users, thus leverage. Reddit Enhancement Suite, for example, is completely crippled by this bug. Having to explain to roughly 250,000 users that they need to add a cookies exception is not an easy task especially given the varying level of technical experience/comfort that exists in a group that large. At the very least, an interface for developers to explain this to users or build in a permissions list for 3rd party to the manifest (and yes, go ahead and prompt the user and explain about it on install) would go a long way towards making addons work seamlessly. I'd really like to see some sort of a better solution than a wontfix. Optimally, I'd like it to "just work", but I can understand Mozilla's privacy-centric concerns here and think that at the very least, extension developers should have some means of getting users around this problem that's better than responding to loads of individual bug reports. Thanks for your consideration.
I just got a question about this from a user on irc. Sounds like from the priority flag this is possible for the 57 timeframe, but not certain that we can get to it. If not, then maybe for 58.
status-firefox57: --- → affected
What's the current status of this? It's really important for any extension that enhances or hooks into a site's API to make requests on the user's behalf. We've had tons of users get tripped up by this since we've moved to WebExtensions and functionality-wise this is definitely a regression from the Addon SDK. Like RES, New XKit is entirely built around this behavior and wouldn't function without the ability to make 1st-party requests on the user's behalf. To clarify, this is the policy we think makes sense here: "Content scripts that are embedded *on* a origin, should be able to make requests *as* that origin". I don't think this is "[working] around how the platform is supposed to work for cookies".
Flags: needinfo?(kmaglione+bmo) → needinfo?(amckay)
If I understand the STR and comments correctly, this doesn't need a WebExtension to recreate, so based on comment 12 and the other comments moving over to Core. If this is the intended behavior from this configuration then we should probably document this.
webextensions: + → ---
status-firefox58: --- → wontfix
status-firefox59: --- → fix-optional
Component: WebExtensions: Untriaged → Networking: Cookies
Flags: needinfo?(amckay)
Product: Toolkit → Core
Whiteboard: triaged → [necko-triaged] triaged
Since the status of this is "status-firefox59: --- → fix-optional", has this been fixed in version 59? If not are there any plans for bugfix versions to include the fix?
Since this is different behaviour from Chrome, I’m adding it as a blocker to bug 1161828.
Blocks: webextensions-chrome-gaps
Any update on this? some extensions depend on this you know.
Sorry. Forget my previous reply. I was confusing this issue with another one.

This has probably sat untouched since it remained assigned (to me) when moved to core:networking. I'd like to get input from that team and see if we can move this forward.

Selena, can you help find someone to poke at this?

Assignee: mixedpuppy → nobody
Flags: needinfo?(sdeckelmann)

:miket, :ddurst -- Can you both weigh in on the prioritization of this? From my viewpoint the end state of this seems confusing for a user in private browsing mode, but it appears that the Chrome extensions API supports it, making it a potentially ambitious webcompat/add-ons crossover.

Flags: needinfo?(sdeckelmann)
Flags: needinfo?(miket)
Flags: needinfo?(ddurst)
Summary: WebExtensions request does not contain cookies even for visited sites when 'from visited' setting is enabled → WebExtensions request does not contain cookies even for visited sites when 'from visited' setting is enabled, in Private Browsing mode

Arthur - interested in your take on this as well.

Flags: needinfo?(arthur)

If the OP still holds (manually visiting the site appends the cookies, but requests from an extension context do not append the cookies), then I think we should P2 this, as the reasonable assertion is that the content blocking settings are respected, even when in private browsing mode. [Or, to put it another way, that content blocking wouldn't be different in some contexts when in private browsing mode.]

Flags: needinfo?(ddurst)

From the perspective of add-ons interop (which might lead people to think pages are broken), it seems reasonable to match Chrome here.

Flags: needinfo?(miket)

I agree with David and Mike that fixing this to match Chrome and meet the expectation of users seems the right approach.

Flags: needinfo?(arthur)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

Can you take a look?

Flags: needinfo?(ehsan)

I can definitely take a look. The first step for me is to understand what the broken behaviour is. I'm a bit stuck on that for now...

Shane, I'm going off of your test case in attachment 8827265 [details] [diff] [review]. In that test, I do not see where the bug is. We open http://mochi.test:8888/..../file_sample.html, it tries to set a cookie using document.cookie, that fails because cookieBehavior == 3 (since there are no existing cookies from mochi.test) and then the rest of the test fails.

Can you please clarify what is the exact set of steps that are expected to work, and why do we expect them to work? Thanks!

Flags: needinfo?(ehsan) → needinfo?(mixedpuppy)

Oh wait, I think I misunderstood the bug originally. This bug actually isn't related to web extensions at all. The implementation of the "from visited" cookie policy is just broken under private browsing mode it seems! It was just noticed with WebExtensions...

Assignee: nobody → ehsan
Flags: needinfo?(mixedpuppy)
Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8e3be55481b9 Fix the implementation of the 'from visited' cookie policy in private browsing mode; r=baku

https://hg.mozilla.org/mozilla-central/rev/8e3be55481b9

Status: NEW → RESOLVED
Closed: 8 years ago → 5 years ago
status-firefox74: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: