Open Lucki opened 5 years ago
Firefox is now adding "Origin Attributes" to the origin used for cookies/localStorage/IndexedDB and XHR/fetch requests. They started with Firefox 53 (and revamped the API in 57).
The advantage for them is that two tabs on the same page with different origins can be logged in (or not) independently.
The issue for us is that we don't currently track the new origin and can't distinguish between the multiple possible login states. The underlying feature is "contextualIdentities" (https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/) and Mozilla published a guide for extension authors: https://hacks.mozilla.org/2017/10/containers-for-add-on-developers/
With the cookies
permission we should be able to access tabs.Tab.cookieStoreId
which is the container the tab belongs to, so we can distinguish between containers.
At present, I don't believe there's any way for an extension to send XHR or fetch requests from the background context with the credentials of any container. Which makes the work to get the extension working under Chrome 73 directly contrary to what's needed for Firefox contextualIdentities.
I think we should start by trying to detect the container and degrading gracefully in that circumstance. (Treat containered pages as logged out as far as the extension is concerned?)
ESGST, an extension for steamgifts, also uses a background page to load stuff from steam. It handles this in the following way: "[…] the default cookies are backed up and replaced by the container cookies while the request is being made, and after the request is done the default cookies are restored."
Issue: https://github.com/gsrafael01/ESGST/issues/631 Commit: https://github.com/gsrafael01/ESGST/commit/52dc2ed30dbba178e4b3bf5870026091783f5fd4
Full option description:
What does it do?
- You should enable this option if you use a single Firefox container for the common sites requested by ESGST that require you to be logged in (SteamGifts, SteamTrades, Steam, SGTools, etc...). With it enabled, ESGST will manipulate your cookies to make sure that requests are sent using the cookies from the current container you are on.
- For example: you are only logged in on SteamGifts and Steam in the personal container. With this option disabled, when you try to sync your owned games on ESGST it will fail because it will use the default cookies (where you are not logged in). With this option enabled, the sync will succeed because the container cookies will be used instead (where you are logged in).
- If you are concerned about what exactly is done, you can check out the source code of the eventPage.js file, where the manipulation occurs. Basically what happens is: the default cookies are backed up and replaced by the container cookies while the request is being made, and after the request is done the default cookies are restored. This is not a pretty solution, but it does the job until a better and more permanent solution comes along.
Another related issue which may also be helpful here: Issue: https://github.com/gsrafael01/ESGST/issues/482#issuecomment-365892403 Commit: https://github.com/gsrafael01/ESGST/commit/19169359083a491eefaef02fbde9de0fe15d97dd
[…] the extension has a background page which allows cross-domain requests to be made (for example, if a request needs to be made to Steam, usually that request would be blocked, since Steam is not in the same domain as SteamGifts, but if the request is made from the background page it's not blocked). But since SteamGifts is in the same domain as SteamGifts, there is no need to make requests to SteamGifts from the background page. So what I did was: if the request is being made to SteamGifts (for example, entering a giveaway) it's now sent from the page itself instead of the background page, which allows all cookies from that page to be sent with it. And that's why it works with Firefox containers. […]
I'm currently implementing a much less dirty solution on ESGST that uses the webRequest
API to intercept requests and set the Cookie
header. I'll reference the commit when I'm done implementing it so that you guys can see how I did it.
I guess the mentioned improvement is that now …
[…] the ID of your current container is retrieved from the tab that initiated the request and used to retrieve the cookies from that container (using the cookies API), then ESGST sends the request with a custom header "Esgst-Cookie" and the request is intercepted by the webRequest API, where the custom header is renamed to "Cookie" so that the cookies can be sent with the request. This is not a pretty solution, but it does the job until a better and more permanent solution comes along.
Issue: https://github.com/rafaelgssa/esgst/issues/1472 Commit: https://github.com/rafaelgssa/esgst/commit/e06b7eb5b1a714feb17a4dbe8802653ce7ee67a3
A workaround is to disable Temporary Containers if you use it, then open SteamCommunity.com in No Container and login. Once you've logged in you can enable Temporary Containers and resume using whichever container you like for Steam. Keep in mind this means there is an active login session in the default container and AS will use that one.
It would also solve the issue with connecting Augmented Steam with IsThereAnyDeal in containers (currently the "connect" button opens new tab in default container even if preferences tab is opened in a different one).
This issue is still present, would be good to have a fix :)
While investigating why the background highlights in the steam community page don't show up we've noticed that the inventory calls probably try to reach out of the current container tab and fails because I'm not logged in there.
My guess to make this work is to only try access the steam cookie for the current container and use that to make the url background calls, but I'm not familiar with the technical stuff. Isthiriel also wanted to give some comments as this probably is something bigger.
https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/