Context identifier for popup/background pages


(Jeenu) #1

Is there’s way I a could associate a context identifier with the browser action popup?

My reading of the API is that you specify a cookie store ID (which you query using a context ID) when you create a tab. For requests other than from a tab (popup, background scripts), I don’t find a way to associate context identifier.


(Martin Giger) #2

Your extension requests have their own context attached by default, so no cookies from the normal browsing context are sent.


(Jeenu) #3

I had a feeling that’d be the case. However, I’d ask user to login to their Google Account (my extension is bookmark-related), so I’d have to do that from a normal Google login page (rather than asking the user to hand over the username and password to the extension). At the same time, I don’t want that particular Google login to install cookies that would be visible to the default browsing session.

So my plan was–if at all possible–to associate the login page with a cookie store, and then re-use that cookie store later to sync bookmarks in the background etc.


(Martin Giger) #4

So this auth flow isn’t OAuth2 since you’re worrying about having access to the cookies later on?


(Jeenu) #5

Not at all. This is just the username/password login that the user does on the usual login page. Only that the extension would like to use the same credentials for future sync etc., and also keep the credentials to itself.


(Martin Giger) #6

I assume the problem here is that it involves sending cookies with your requests, since everything else would be doable. Make a temporary container where the user auths in and get the necessary credentials. Send credentials with requests, done.


(Jeenu) #7

Yes, I figured the getting the ‘user log in in a container tab’ part. What I don’t know is how to reuse that specific credentials when making requests form elsewhere within the extension (say, background page), at a later point in time–i.e., going back to my original question: associating the extension with a cookie store/context identifier other than the default.


(Martin Giger) #8

Yeah, sadly it seems like you’d have to do a lot of work to override the cookies for your requests. You can’t specify a cookie header from fetch, so you’d have to modify them with webRequest and that seems very tedious to me. And then you’d have to manually filter out the incoming cookie header and apply that to your cookie jar, so they don’t end up in the uncontained or whatever jar you have in an extension.


(Jeenu) #9

Sigh… that confirms my inkling. Thanks.