Cookies are no longer stored by nsIHttpChannel?

[john.b...@googlemail.com]

Hi,

I have run into something strange. This is how I create network connections in my (Thunderbird-) AddOn:

let channel = Services.io.newChannelFromURI(
aConnection.uri,
null,
Services.scriptSecurityManager.createCodebasePrincipal(aConnection.uri, { userContextId }),
null,
Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL,
Ci.nsIContentPolicy.TYPE_OTHER);

let httpchannel = channel.QueryInterface(Components.interfaces.nsIHttpChannel);
httpchannel.loadFlags |= Ci.nsIRequest.LOAD_BYPASS_CACHE;

After updating from ESR60 to ESR68, that connection never uses cookies anymore. This is a fresh profile, so there are no specific cookie settings being set (network.cookie.cookieBehavior = 0).

I can see the request from the server to set cookies on each request, but on the next response, the cookies are not included.

This is used for standard HTTP requests (CardDAV in my case).

Can someone point me to what I am missing?

Thanks,
John

[Honza Bambas]

This might be a cookie isolation, or something missing to recognize if
the cookie storage is allowed for the channel.  Is the `userContextId`
the same all the time? If yes, can you capture a log with
nsHttp:5,cookie:5?  Checking browser console for errors may tell you
something too.

CC'ing Ehsan directly in case he spots something immediately from your
code.  My own cookie-fu is not strong enough at the moment.

-hb-

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[john.b...@googlemail.com]

It happens also with the SystemPrincipal as well, so independent of the userContextId. I changed to code as follows now and get the same behaviour:

let channel = Services.io.newChannelFromURI(
uri,
null,
Services.scriptSecurityManager.getSystemPrincipal(),
null,
Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL | Ci.nsILoadInfo.SEC_COOKIES_INCLUDE,
Ci.nsIContentPolicy.TYPE_OTHER);

let httpchannel = channel.QueryInterface(Ci.nsIHttpChannel);
httpchannel.loadFlags |= Ci.nsIRequest.LOAD_BYPASS_CACHE;

I can see Set-Cookie headers in the responses from the server, but requests send out by my channel do not include any. Hm ...

[john.b...@googlemail.com]

More details: The same code works in TB60 and in the cookie list of the general options I can see all sorts of cookies being stored. In TB68, none of the expected cookies show up in the cookie list.

Did something change in that region? What do I need to do to allow a channel / principal to store cookies now?

[Andrea Marchesini]

The issue is about the use of nsICookieSettings. If you create a channel
without an associated document, by default, we create a new
nsICookieSettings which blocks cookies.
The idea behind this decision is that chrome code, by default should not
send/receive cookies. A good description of what nsICookieSettings is can
be found here:
https://searchfox.org/mozilla-central/rev/7ed8e2d3d1d7a1464ba42763a33fd2e60efcaedc/netwerk/cookie/CookieSettings.h#20

About your particular use-case, there are 3 ways to proceed:
1. create and set a cookieSettings object in the loadInfo of your channel
before calling asyncOpen()/open(). - hard to do because CookieSettings
cannot be created from JS yet.
2. create a channel from a document/worker. - recommended!
3. disable the cookieSettings block: see pref
network.cookieSettings.unblocked_for_testing - you don't want this!

We can move this discussion on slack/bugzilla/irc.

[john.b...@googlemail.com]

Hi Andrea,

I was already going thru that CookieSettings docuemnt, but are you sure that is alreadfy in the ESR68 branch? I tried to access loadInfo.cookieSettings and got back an error.

Where can I find you on IRC? Which channel/nick?

[Andrea Marchesini]

Yes, nsiCookieSettings landed in FF67. And it's in ESR68:
https://hg.mozilla.org/releases/mozilla-esr68/file/tip/netwerk/cookie/nsICookieSettings.idl
What blocks your cookies is probably this:
https://hg.mozilla.org/releases/mozilla-esr68/file/tip/netwerk/base/LoadInfo.cpp#l754

[john.b...@googlemail.com]

Hi Andrea,

I can confirm, that

network.cookieSettings.unblocked_for_testing

is indeed fixing this for me. But since this pref looks like it will not stay long, I would like to fix this with the worker approach.

You said you would like to move this discussione to IRC, where can I find you?

Thanks for your help!

[Andrea Marchesini]

> You said you would like to move this discussione to IRC, where can I find
> you?
>
>

Yes, let's continue this discussion on IRC. My nickname is "baku".

Thanks for your help!
>

np