https://supertokens.com/
Join Discord
Hello guys ! I have an issue with the logout on safari and on mobile. The server send a 200 but with...
# support-questions-legacy
r
Hello guys ! I have an issue with the logout on safari and on mobile. The server send a 200 but without the set-cookie header so the user is still login after the logout. Is is a known issue ? Is there a workaround ?
r
hey @ronflai can i see the set-cookie response header when you call the sign in API? A screenshot will do. Also, whats the value of your apiDomain and websiteDomain?
r
the set token response is too long to be display in our monitoring tool but there is main part
r
whats the value of sameSite for the cookies?
r
SameSite=none;
r
right. So safari doesn't respect that
switch to using header based auth instead of cookie based
search in our docs for "token transfer method"
and then things should work
r
can you indicate me the correct doc to follow for safari ?
r
there is no docs specific to safari
r
but in safari and on desktop it s work
r
you should just change to using header based auth
safari desktop should not work with sameSite none eithert
unless you have changed the browser's setting
r
what change should we make for this to work ?
r
search for "token transfer method" in our docs please
or you can tell me which recipe you use and i can send a link
r
ok I found the doc but to understand it will send the token using header and not cookie right ?
r
yes.
You don't need to do anythign really
just set the config as per the docs
and try again - it should work
r
but it s not really safe to send the token using header ?
r
it's less secure - yea
the only other way to solve this is to use websiteDomain and apiDomain that share a same base domain
so that the cookie sameSite resolves to 
lax
and then it will work on safari as well
r
ok thanks for the info
And why the signin work then ? because now the signin is working fine is juste the logout
r
cause sign in sends the cookies.. it's the browser which is ignoring it
and logout requires cookies to work. So since the browser did not save them, it won't work
r
but we have the token in browser because otherwise the Session.doesSessionExist() in the front end should return false ?
r
not really.. there are other tokens on the frontend which are saved using which doesSessionExist works. The ones that the browser ignores are httpOnly cookies.
r
when I try to use the transferMethod: "header" in js app ts complaining that 
tokenTransferMethod' does not exist in type 'UserInput'
what i did is just
Copy code
recipeList: [
        Session.init({
          tokenTransferMethod: "header",
        }),
        Passwordless.init({
          preAPIHook: (context) =>
            addLocaleToCreateCodeRequest(context, activeLocale),
        }),
      ],
r
right. Which version of the frontend sdk are you using?
and which frontend SDK?
r
"supertokens-web-js": "^0.3.0"
r
right. So this feature is only available in version >= 0.5.0
so update to that. Be sure to check the changelog: https://github.com/supertokens/supertokens-web-js/blob/master/CHANGELOG.md
you would also need to update the backend sdk as mentioned in the above changlog
so be sure to checkout the changelog of the backend sdk as well
r
Ok thanks I'll try
I have a new error saying st-auth-mode is not allowed in Access-Control-Expose-Headers is it normal ? do I have to manually change the Access-Control-Expose-Headers ?
r
No. Just update the backend SDK as well
r
Yeah that what I did but still I have this issue
r
Can I see the error on the browser console?
And what are the response headers for the OPTIONS api call? And for the subsequent POST API call (if that happens)
r
response header from api option call
Copy code
access-control-allow-credentials: true
access-control-allow-headers: Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,anti-csrf,rid,fdi-version
access-control-allow-methods: OPTIONS,DELETE,GET,HEAD,PATCH,POST,PUT
access-control-allow-origin: http://localhost:3001
content-length: 1
content-type: application/json
date: Thu, 09 Mar 2023 15:19:35 GMT
via: 1.1 8cea2743cbaa04c70ebc2ec4f5892fa6.cloudfront.net (CloudFront)
x-amz-apigw-id: BhPZNFNFliAFYPA=
x-amz-cf-id: WEmof5X7ZtZWyyf6IHPrriP5E-lhMZ7rlrXyohwZ_jegi43mPcRmyQ==
x-amz-cf-pop: CDG52-P4
x-amzn-requestid: 91db72e8-86d0-4f7c-9aa4-439b931ea796
x-cache: Miss from cloudfront
r
Right, so you need to add st-auth-mode header to AWS CORS setting too. Similar to how you added rid
r
Oh yes you right I forgot about that
I see that now we have st-xxx cookies for access token and refresh token but the access token has a validity of several days instead of 1 hour as before
so there is no refresh mechanism ?
r
there is
the access token cookie saved in storage is saved for a long time, but the token's expiry itself is just 1 hour
so even if the token is sent to the backend and it's been more than an hour, the backend will reject it and trigger a refresh flow.
r
ok so the expiration is in your system right ?
r
Yes
r
Ok thank for the clarifications, I also noticed that the 
attemptRefreshingSession()
is returning a 401 now instead of returning false if the st-access-token is not there
r
right yea. Cause the st-access-token needs to be there for it to work (this is an implementation detail). But even if the access token has expired, st-access-token will still be there resulting in 
attemptRefreshingSession
to continue working
the only time it will break is if you manually clear the st-access-token (Which is what i assume you did right now)
r
yes indeed I'm testing flow
again thanks for the clarifications
and in which case the 
attemptRefreshingSession
could return false ?
r
when the user is completely logged out
r
alright gotcha ! Thanks
r
i.e., no access token, no refresh token and also 
st-last-access-token-update
is present in the cookie storage
PreviousNext
Powered by

SuperTokens.com

SuperTokens is an open source authentication solution offering features like: Different types of login: Email / password, Passwordless (OTP or Magic link based).

Powered by