https://supertokens.com/ logo
Join DiscordCommunities
Powered by
Hi, I'm trying to setup auth with my chrome extens...
# support-questions-legacy
u
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 ?
r
Hey! Are you using axios? If yes, have you added our axios interceptor?
u
not using axios no
r
Are you calling supertokens.init on the chrome extension before making the API call?
Then are you using fetch?
u
using fetch yes, not initializing supertoken on the extension at all
r
Oh. You need to. We add interceptors for fetch as well. Which needs to be there
u
I don't understand how that would help, because the cookies are not controllable by fetch
my setup works locally because everything is on localhost
in production however, my webapp is on a different domain than my api
r
Well, it does add the config of credentials: include to the request which tells the browser to add cookies. Also it does automatic refreshing.
u
ok, I've added the credentials: include to all fetch calls in the extension
it all works locally, I can login in the webapp, then make authenticated calls to my api from the extension, because it sends the cookies along
It doesn't work in prod though...
r
Hmmm. In prod, can I see the set-cookie header response when the login api is called?
Like a screenshot of that as it’s visible on chrome
u
you can see the samesite=None in there
r
Which backend SDK are you using?
And which version of it?
u
"supertokens-node": "^11.0.0"
r
And which framework?
Express or something else?
u
Interestingly, even with samesite=none, the application tab of hte dev tools still shows the cookies as "lax"
my backend framework is fastify
r
I see. Thanks.
Those two are frontend set cookies
So the cookies do seem to get set
and can I see the request headers for when u make an api call?
Post login
u
from the webapp or the extension ?
r
extension
Also, could you upgrade to the latest backend SDK version? There was a fastify bug that was fixed which set sAccessToken multiple times in the response (as you are seeing in the screenshot above)
u
so from the extension there's nothing
r
To further clarify, do the cookies get sent from the webapp in prod? Or not there either?
u
funny, I think I reported that
yea the cookies are all good in teh webapp in prod, I can login & make authenticated calls
r
no credentials include header. Are you sure that that is being set correctly in your requests?
u
all calls by the extension are using this init
r
oh actually, nvm.. it seems that that header is not shown in the request on chrome.
hmm this is strange
> yea the cookies are all good in teh webapp in prod, I can login & make authenticated calls Since this is happening, there probably isn't a config error anywhere.. something specific to extensions that's going wrong
u
yea that's something I looked into, but I can't set cookies with fetch, so getting them is kinda useless
r
Fair enough
Any console log on the browser when making the api call?
u
nothing more than what I log manually, which is basically supertokens's answer to my cookie-less calls {message: "unauthorized"}
r
Hmmm
Can you access localstorage of the web app that you login from? (From your browser extension)
u
yeah, so basically I could send message from the webapp to my extension, which could potentially be a jwt token
but tbh I was trying to avoid setting up jwts entirely
authenticating extensions is really hard :/
r
Okay. So maybe you can consider monkey patching supertokens to not use cookies and instead use regular headers and saving them in localstorage instead.
u
mmh okay I'll try to look into that
thanks for the help
r
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.
the example app is for express backend, but im sure there is a way to do something very similar for fastify
lmk if it works! (or if it does not)
u
okay thanks, I'll let you know !
r
Sounds good!
u
Hey so I've got almost everything working
I managed to send the custom header content to my extension & use it there, but I'm getting a "try refresh token" response from supertokens
r
Right. This means the access token has expired and you need to refresh the session
In order to do that, you should either use our SDK on the chrome extension as well (you can initialise just the session recipe for it), or then you have to call the refresh api yourself
u
I'm triggering a request from the extension seconds after sending it the header though :/
r
Hmm. This means something else is broken. Can you enable backend debug logs and show the output?
u
sure I'll try
ok so there's this line in there 
2022-08-07T18:45:46.077Z com.supertokens {t: "2022-08-07T18:45:46.077Z", message: "getSession: Returning TRY_REFRESH_TOKEN because custom header (rid) was not passed", file: "/app/node_modules/supertokens-node/lib/build/recipe/session/sessionFunctions.js:197:30" sdkVer: "11.0.3"}
which i'm guessing is related
r
Ah yes. In your fetch request, just set the header “rid: anti-csrf”
This is to prevent CSRF attacks since sameSite cookie is none.
But honestly, since u r using custom headers now, you can set same site cookie to lax and this error should go away on its own
u
ok well this totally worked
r
Cool
u
and that was prod
many thanks to you for your top notch support (this is like the third time I'm bothering you)
r
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
u
I have another quick question: if I trigger a refresh from the extension will that mess up with the session of the webapp ?
in other words, can both the webapp and the extension refresh on their own
r
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.
u
ok cool
r
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
u
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.
Yeah okay, I'm expecting to have to source the custom header from the same place for both the webapp and the extension, but that should be a lot less painful
12 Views
PreviousNext
Powered by