Support Web Extension MV3 service worker as context

[sublimator]

Google are aggressively moving everyone to Manifest Version 3 for Web Extensions. This change moves the background page to an ephemeral Service Worker. localStorage and other window objects are no longer available This library sadly won't work

[rishabhpoddar]

How would you go about persisting data in that case?

We also allow you to override the window functions used by the lib (see https://github.com/supertokens/supertokens-web-js/blob/master/lib/ts/types.ts#L60 and https://github.com/supertokens/supertokens-web-js/blob/master/lib/ts/types.ts#L48) - would this help?

[sublimator]

Thanks for the links! Yes, maybe that's enough :)

How would you go about persisting data in that case?

There are various options: IndexedDB, Web Extension storage apis etc

[sublimator]

From our extension's background page we are able to make authenticated requests to our website, using cookies that are set by the website. However, it's not uncommon for users to not visit the website for long periods, while using the extension daily. This means that we must refresh tokens from in the extension.

Am I right that these are SuperTokens cookies?

sIRTFrontend=b86ee1ce-41a9-4e05-a1dc-5543ee7d8dca; 
sFrontToken=eyJ1aWQiOiI....TQwZDQtYTQxNS 

What do these do? We would need to set these cookies somehow on the website domain?

[rishabhpoddar]

These are supertokens cookies indeed. They are set on the frontend cookies which allow the frontend to know if a session exist and get the payload from the access token.

They are not used by the backend to do session verification. The tokens used by the backend are attached to the API domain and are:

• sAccessToken
• sIdRefreshToken
• sRefreshToken

So if the frontend ones (sIRTFrontend and sFrontToken), are not accessible, it may cause extra calls to the refresh API which will set these in frontend cookies (by default), but you can override those handlers to set them elsewhere - where browser extensions are allowed to store data.

[sublimator]

Thanks!

[sublimator]

It seems window must be defined to get fetch https://github.com/supertokens/supertokens-website/blob/master/lib/ts/fetch.ts#L166

[rishabhpoddar]

Hmmm. You could set global.window = {fetch: ..., ...} perhaps before calling supertokens.init. Will that not work?

[sublimator]

Yeah, I did do that and it got past the error, but I would prefer not to

[rishabhpoddar]

Fair enough. We will figure something for that

[sublimator]

Thanks! I will let you know if I come across anything else

[sublimator]

@rishabhpoddar

So I cloned the supertokens-website repo ( sorry, I opened this issue in the wrong repository ) and did some find usages and the only internal usages I found for the window handler seemed to be location.getHostName() and location.getOrigin(). There seemed to be none for the cookie handler.

Does this repo (supertokens-web-js) make more use of the interfaces ?

[rishabhpoddar]

Cookie handler is being used in supertokens-website as well. See this as an example: https://github.com/supertokens/supertokens-website/blob/master/lib/ts/fetch.ts#L555

[sublimator]

So, my IDE must have got confused as well :) It wasn't showing that usage I'll take a further look

[sublimator]

@rishabhpoddar

Hi, so it seems the browser-tabs-lock module also assumes a window environment with localStorage:

[rishabhpoddar]

Ah right!! Thanks. Will modify this as well.

[sublimator]

Thanks!

[sublimator]

Any update here @rishabhpoddar ?

[rishabhpoddar]

hey @sublimator none yet - sorry. Didn't get bandwidth to do this and probably won't be done anytime soon.

You may want to fork browser tabs lock and change that part of the code and use your forked version instead of what we use.

[sublimator]

@rishabhpoddar

Could you take a quick look at this please and see if it will fly ?

https://github.com/supertokens/supertokens-website/pull/186

[rishabhpoddar]

@sublimator i have merged the PR and added it to our test pipeline. Once that's tested, i'll release the SDK and close this issue.

[sublimator]

Maybe I should make a PR to fix "window must be defined to get fetch" ?

[sublimator]

AuthHttpRequest.env = getWindowOrThrow().fetch === undefined ? global : getWindowOrThrow();

I believe you could just set that to self and it would work. Do you need to support relic browsers ?

Actually, I don't quite understand that global reference. What is that there to support? Given it will throw if it can't find window?

[porcellus]

We are adding a new getWindowUnsafe method to window handler reference in the next release of the website SDK. Providing that function and returning self would solve the "window must be defined to get fetch" issue. Could you try using this https://github.com/supertokens/supertokens-website/tree/15.0 branch to see if it resolves your issue?

[sublimator]

That /seems/ to work, but it's the end of the day and I haven't tested thoroughly Can get you more info tomorrow, otherwise 15.0 looks pretty good

[rishabhpoddar]

@sublimator we have released the new version of the SDK on npm (v15.0.0).

[rishabhpoddar]

@sublimator i have also added you to the readme on the supertokens-core repo :) Thanks

[sublimator]

@rishabhpoddar

Hey, sorry, I missed the notification,

A very late "thank you!!" :)