Hi, I'm trying to setup auth with my chrome extension, I've browsed past questions about this problem, and it seems the most straightforward solution is to use jwt with localstorage. But there's a couple things I'm still wondering: - I've tried setting the

cookieSameSite

option to none, and I can see that it is indeed set with the option, however, when launching request from the extension, the cookies are not there, why is that the case ? - If choosing to use the jwt with localstorage approach, does it mean that refresh the session does not work anymore ?

Hey! Are you using axios? If yes, have you added our axios interceptor?

not using axios no

Are you calling supertokens.init on the chrome extension before making the API call?

using fetch yes, not initializing supertoken on the extension at all

Oh. You need to. We add interceptors for fetch as well. Which needs to be there

I don't understand how that would help, because the cookies are not controllable by fetch

Well, it does add the config of credentials: include to the request which tells the browser to add cookies. Also it does automatic refreshing.

ok, I've added the credentials: include to all fetch calls in the extension

Hmmm. In prod, can I see the set-cookie header response when the login api is called?

Which backend SDK are you using?

"supertokens-node": "^11.0.0"

And which framework?

Interestingly, even with samesite=none, the application tab of hte dev tools still shows the cookies as "lax"

I see. Thanks.

from the webapp or the extension ?

extension

so from the extension there's nothing

To further clarify, do the cookies get sent from the webapp in prod? Or not there either?

funny, I think I reported that

no credentials include header. Are you sure that that is being set correctly in your requests?

all calls by the extension are using this init

oh actually, nvm.. it seems that that header is not shown in the request on chrome.

yea that's something I looked into, but I can't set cookies with fetch, so getting them is kinda useless

Fair enough

nothing more than what I log manually, which is basically supertokens's answer to my cookie-less calls {message: "unauthorized"}

Hmmm

yeah, so basically I could send message from the webapp to my extension, which could potentially be a jwt token

Okay. So maybe you can consider monkey patching supertokens to not use cookies and instead use regular headers and saving them in localstorage instead.

mmh okay I'll try to look into that

so all the tokens stay the same.. except that you use localstorage to save them instead of cookies, and you use some custom headers to communicate those when making API calls. Instead of cookies and set-cookie headers.

okay thanks, I'll let you know !

Sounds good!

Hey so I've got almost everything working

Right. This means the access token has expired and you need to refresh the session

I'm triggering a request from the extension seconds after sending it the header though :/

Hmm. This means something else is broken. Can you enable backend debug logs and show the output?

sure I'll try

Ah yes. In your fetch request, just set the header “rid: anti-csrf”

ok well this totally worked

Cool

and that was prod

Haha! Happy to help. If you can contribute a demo app for working with browser extensions, that would be great. There have been people in the past who have asked for this

I have another quick question: if I trigger a refresh from the extension will that mess up with the session of the webapp ?

As long as you save the new access and refresh tokens in the same place that the web app reads them from, it should be fine.

ok cool

Also, keep in mind that sometimes calling getSession / verifySession changes the access token as well, or if you call updateAccessTokenPayload in your APIs, it would change the access token. In that case, the response from the api would have a new access and a front token. So you should save those as well

yeah I'll definitely think about that, it's a real pain to setup, I think your idea of using custom headers is the simplest one (there's a couple other convoluted ones), then there's some communication that needs to happen between the webapp and the extension... Anyway, I'll try to remember to send a PR your way for all of that.