How to handle login cookies being marked as third party?

[Tycho Bokdam]

I'm in the users group that has third party cookies blocked and we notice that this causes our extension to no longer work as our session cookie is now blocked. 

I can't seem to find any documentation on this yet. How should we handle our session cookie in this case? Can we validate our domain somewhere so those cookies are allowed?

[Oliver Dunk]

Hi Tycho,

Would you be able to share some more about how you're using cookies in your extension? For example, is this a cookie your extension sets or is it set by a third-party and you are trying to read it? What context is this in?

We have some documentation here which may help: https://developer.chrome.com/docs/extensions/develop/concepts/storage-and-cookies. That said, this is a nuanced topic and there are still some intricacies that haven't made it into the documentation yet.

Happy to help figure this out with you.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

On Wed, Jan 17, 2024 at 1:25 PM 'Tycho Bokdam' via Chromium Extensions <chromium-...@chromium.org> wrote:

I'm in the users group that has third party cookies blocked and we notice that this causes our extension to no longer work as our session cookie is now blocked. 

I can't seem to find any documentation on this yet. How should we handle our session cookie in this case? Can we validate our domain somewhere so those cookies are allowed?

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/7fd850a2-1853-4666-a751-6dbedb84b469n%40chromium.org.

[Tycho Bokdam]

Hi Oliver,

Yes ofc, so our users need to login to use the extension, when they login our API returns with a set-cookie header containing the cookie that needs to be send with the calls to our API.

Normally this is not an issue as the domain the APP is running on is the same as the API, but in the case of the extension the domain does not match so it sees it as a third party cookie.

Note: this is only an issue for the iframe we add to the page when someone clicks on the extension icon, the background.js keeps working fine.

[Oliver Dunk]

Thanks Tycho. A couple of extra questions:

• Does your extension have host permissions for the API?
• Are you trying to read the cookie from the response or just want to make sure it is set on the domain and included in future requests?

Appreciate your patience.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Tycho Bokdam]

We indeed have "host_permissions" set for the domain/full endpoint the cookies should be send to.

We only want it to included indeed into future requests, something that now does happen when you have the third party cookies enabled.

[Oliver Dunk]

Hi Tycho,

To confirm, is the request being initiated from an extension page in an iframe which is an immediate child of the top-level site? If so, the cookie should be included as long as you have host permissions for the API. This is because it will be treated as a same site request: https://www.chromium.org/updates/same-site/test-debug/#testing-chrome-extensions

If you're not seeing this, is there anything more complicated about the page hierarchy that may explain it? Alternatively, is it a public extension I could experiment with?

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Tycho Bokdam]

It is indeed an extension page in the iframe, we do have host_permissions set to the domain but it does not seem to work.

Example:

"host_permissions": ["http://localhost:8080/app/rpc/"],

And the API calls are done to http://localhost:8080/app/rpc/. Ofc in prod we use our actual domain.

The extension is not "public" (login required).

[Tycho Bokdam]

Would also like to add, the cookies do seem to be stored for the background service worker, there everything is working fine it's just the iframe that does not add the cookie to the requests.

[Oliver Dunk]

Hmm, I would expect that to work and it seems to be working on my end.

I put a test extension here - if you install it locally and try the following:

1. Go to https://example.com/
2. Open DevTools
3. Click the extension's action icon
4. Look at the second network request in DevTools

Do you see the cookie set in the Set-Cookie request header?

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Tycho Bokdam]

Sorry for the late reply, was off for a couple days,

I tested your extension, I see the requests returning "Set-Cookie" but it also has a little warning sign behind it saying "setting this cookie was blocked due third party cookie phaseout".

[Oliver Dunk]

Hi Tycho,

Thanks for testing - I'm seeing the same now, so I'm really sorry. I must have been in a bad state when I tried this last.

Based on what I'm seeing, it appears that the SameSite exception I mentioned isn't applying when third-party cookies are blocked. I'm going to figure out if that is intentional, but in the meantime, it seems like that is the current state of things.

If signing in within the iframe is an option, you might be able to use partitioned cookies. Otherwise, proxying through the background is likely your best option at the moment.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Tycho Bokdam]

Thanks!

Was indeed looking at proxying all the calls, so will continue with that for now.