Enabling third party cookie blocking makes nsICookieService::getCookieString useless for chrome callers

RESOLVED DUPLICATE of bug 437174

Status

()

RESOLVED DUPLICATE of bug 437174
10 years ago
10 years ago

People

(Reporter: mozbugs, Unassigned)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
Due to bug #421494, there seems to be no straightforward way for a privileged caller to get nsICookieService::getCookieString to work for *any* cookie if third-party cookies are blocked in prefs. This makes the method effectively useless.

Flock relies on this to do login detection for some service integrations.

I propose adding a third method to nsICookieService for privileged callers, which bypasses both the third party check as well as allows getting at httpOnly cookies.
Blocks: 421494
Flags: blocking1.9.1?
Keywords: regression

Comment 1

10 years ago
This is affecting some of our extensions as well.  I think passing a null channel to getCookieString() should bypass the "third party" cookie checks.  Privileged code can work around any such restrictions in any case, so why make it difficult?
(Reporter)

Comment 2

10 years ago
I thought of that, but I wasn't sure if there are places in the code where the channel is null that *should* reject cookie access though.

Comment 3

10 years ago
passing a null channel won't bypass anything - the third party checks are now implemented in a way that can't easily be bypassed. of course these things can be worked around, but we're not out to prevent that - we're trying to prevent the casual case of "kick off a load from this URI", whether from chrome or not, from opening third party privacy holes. see bug 437174 comment 27, and the original bug, for more explanation.

it's unclear exactly what you're trying to do, but to programmatically look at cookies you shouldn't be using the getCookieString API, rather the methods on nsICookieManager{2} that offer you nsICookie2 objects directly. of course, we don't have a convenient API method to get the cookie objects for a given host yet, but we can trivially add that.

for the general case of loads/channels etc trying to get cookies regardless of third party prefs, this is really the same bug as 437174. as filed, this is about getCookieString, so duping over there.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 437174

Comment 4

10 years ago
(In reply to comment #3)
> of course, we  don't have a convenient API method to get the cookie objects
> for a given host yet, but we can trivially add that.

fyi, the patch in bug 423132 adds this method.
(Reporter)

Comment 5

10 years ago
(In reply to comment #3)
> it's unclear exactly what you're trying to do, but to programmatically look at
> cookies you shouldn't be using the getCookieString API, rather the methods on
> nsICookieManager{2} that offer you nsICookie2 objects directly. of course, we
> don't have a convenient API method to get the cookie objects for a given host
> yet, but we can trivially add that.

It's not practical to look through *all* of the cookie store just to get cookies for one host, so yes, this API is needed in lieu of this.

Updated

10 years ago
Flags: blocking1.9.1?
You need to log in before you can comment on or make changes to this bug.