Extend roadmap: cookies

[sadym-chromium]

No description provided.

[jgraham]

The big practical question for cookies is how to handle double keyed cookies (maybe more generally multi-keyed cookies) i.e. situations where the cookies sent depend both on the origin of the request and the origin of the request source. Current WebDriver entirely punts on this issue and just says "return the entire content of the cookie store", without any way to tell which cookies will actually apply to a given request, or set the key for cookies.

[sadym-chromium]

TODO: allow cross-origin cookies access

[mathiasbynens]

The big practical question for cookies is how to handle double keyed cookies (maybe more generally multi-keyed cookies) i.e. situations where the cookies sent depend both on the origin of the request and the origin of the request source.

For my own understanding: is this only about SameSite cookies, or does double-keying apply to more scenarios?

@OrKoN How does CDP handle this, if at all? CDP’s Network.getCookies seems to only accept a list of URLs, returning all applicable cookies for those URLs — allowing to specify only one out of two “keys”. https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-getCookies

[OrKoN]

@mathiasbynens we should probably be using https://chromedevtools.github.io/devtools-protocol/tot/Storage/#method-getCookies which has partition keys (I assume that it is used for double-keying?)

[jgraham]

See https://hacks.mozilla.org/2021/02/introducing-state-partitioning/ for example.

Basically it means that cookies are keyed not just on the destination origin (e.g. example.org only gets example.org cookies), but also on the source origin i.e. a request from example.net for an example.org resource doesn't see cookies for example.org that were set as part of a request from example.com (or any other origin).

Also, at least in Gecko, we have the concept of containers, which are used as an additional key for storage. It's unclear to me how we want this to work for WebDriver. For example if we want a feature to partition storage between different tests, using containers for that partitioning makes sense. But then should getting cookies return cookies for all containers, or require specifying which container to use? This might also apply to WebKit/Safari's profiles; I'm not sure (it doesn't apply to Firefox profiles because there's a 1:1 relationship between a browser process and a profile, but 1:many between a browser process and containers).

[lolaodelola]

Hi @sadym-chromium, just wanted to know if you're waiting for anything in particular to get this merged? Since work on cookies is being discussed & definitely going to happen, it'd be good to have this in the main roadmap.

[thiagowfx]

@lolaodelola FYI Maksim is on leave. You may want to reach out to @mathiasbynens privately in the meantime to discuss the next steps.

[mathiasbynens]

I’ve marked the PR as ready for review now. I agree it would make sense to merge this in some form, since we already agreed that this is important and happening.

[OrKoN]

LGTM % suggestion to make scenario a bit more specific.

[jgraham]

This doesn't cover cookies for pages that aren't loaded. My understanding is that the need to load a page before interacting with its cookies is considered a significant limitation for WebDriver. It's also the source of much of the complexity here (since having a page loaded in a specific context answers a lot of the questions around keying, given that a particular browsing context will have a particular storage key).

[mathiasbynens]

Any suggested edit?

[mathiasbynens]

Is this addressed by the edit that happened after this comment was posted?