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

Status: RESOLVED DUPLICATE of bug 437174

(Core :: Networking: Cookies, defect)

Description

[Manish Singh]

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.

Comment 1

[Mark Smith [:mcs]]

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?

Comment 2

[Manish Singh]

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

[[e-mail]]

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.

Comment 4

[[e-mail]]

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

Comment 5

[Manish Singh]

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