Hey, I have run into the infamous Safari itp blocker. I trying to get a password less flow with otp codes working in a iframed environtment under a page that we don't control the domain on. So we cant serve out content from the correct domain. I have switched to the header

tokenTransferMethod: "header"

flow instead of the cookie based one as suggested. Everything works fine in chrome and firefox, the

authorization

header gets set with the expected value and the backend is able to authenticate the request. But in safari no header is provided, which causes the flow to not work. The consome call for the otp works fine and we get a response from the server containing all the expected tokens. But the following request to the api does not contain anything and returns with a 401. After digging around a bit it in https://github.com/supertokens/supertokens-website/blob/master/lib/ts/fetch.ts it looks like even when using the header mode all the tokens still gets stored as cookies by the client and this will then also fail because of itp. But setting values in localstorage/session should still work, with some limitations, but it should get the flow running as expected for the current session at least. So is there a way to totally disable cookies and only store all the tokens in local storage when header mode is active?

hey @urbansson the setting of the cookies is related to the frontend cookies. So that's not the problem. Can you share the session.init of your frontend?

Sure it currently looks like this:

typescript
export const config: SuperTokensConfig = {
  appInfo: {
    apiDomain: getApiHost(), // Resolves to https://192.168.1.7:6789
    apiBasePath: "/auth",
    appName: 'Test App',
  },
  enableDebugLogs: true,
  recipeList: [
    Passwordless.init(),
    Session.init({
      isInIframe: true,
      tokenTransferMethod: "header"
    }),
  ],
};

i see.

And then called like this

SuperTokens.init(config);

@alisheraituarov can help out.

Just testing setting cookies in the frontend in safari with

document.cookie ="foo"

and then trying to access it with

document.cookie

returns empty string. So I'm not sure setting cookies in the frontend works. In firefox it does.

Hi, @urbansson are you sure your api is on "/auth" ? and

Passwordless.init()

is missing config

@alisheraituarov it is working on firefox.. so the basic config is fine

checking

hey @urbansson - right. So it's a misunderstanding from our end. You are right that cookies can't be set in an iframe. But IF the user visits the iframe's website on safari (even once) via a top level navigation, then when the iframe is loaded a second time, the cookie setting should work. Can you confirm if this is correct?

Yes, that is correct, but I would like to avoid having to do that. I have also got it to work with

document.requestStorageAccess()

in safari. But both of those flows works but are a bit of a inconvenience for us. We would like it for the login work for the session and can accept that we lose it when the user closes the tab/browser

right. In this case, you can use the custom cookieHandler option on supertokens.init on the frontend to pass in your own implementation of storing to cookies in memory. This would work, but if the user refreshes the page, they will have to login again.

Perfect I will try that! You can set localstorage/sessionstorage in a iframe. But there is some limitations. For safari each instance of the iframe will get its own storage, so you cant share data trough localstorage. In chrome incognito it will be deleted once the session ends.

I see. So instead of storing in memory, you can store in localstorge.. and that should save across page reloads then?

Hopefully!

in chrome icognito, it deosn't seem to allow localstorage either

Yes, just noticed that it now works on everything except chrome incognito.

happy to help! We will push an update fairly soon 🙂

Nice work! I will try this tomorrow

great

Hey, I have tried to update our code with the new changes. But it caused it to break. It currently causes the entire browser to hang on load. I have managed to identify the cuase to line https://github.com/supertokens/supertokens-auth-react/blob/40af56e8964ec067ad4d0a82c9199fd6fef68297/examples/with-next-iframe/config/cookieHandler.js#L110 When that line is removed the app renders and and works, but of course no cookies is set in localstorage so the flow is no longer working. Running with the new window handler but the default cookie handler also works.

that's strange. You notice that it causes it to hang?

I can see both console logs before and after

setKeyValue

hmmm

Sure

ok give me 5 mins please.

1 min, need to fix zoom

yup