Hello - this may be a simple init issue on my part, but sessions don't seem to be working properly in my app (passwordless w/ Flask). When the current session's access token expires, I receive a blank page with the message:

{"message":"try refresh token"}

But I never make it past this point, and I have to manually navigate back to our sign in UI to generate a new magic link. Any ideas what I might be doing wrong here? Here's my frontend init, declared globally in our main js file:

supertokens.init({
  appInfo: {
    apiDomain: "https://staging.<my_url>",
    apiBasePath: "/auth",
    appName: "..."
  },
  recipeList: [
    supertokensSession.init(),
    supertokensPasswordless.init(),
  ],
});

And my backend init (minus custom smtp server recipe):

init(
    app_info=InputAppInfo(
        app_name="...",
        api_domain="https://staging.<my_url>",
        website_domain="https://staging.<my_url>",
        api_base_path="/auth",
        website_base_path="/auth"
    ),
    supertokens_config=SupertokensConfig(
        connection_uri="http://supertokens:3567",
        api_key="<api_key>"
    ),
    framework='flask',
    recipe_list=[
        dashboard.init(api_key="<api_key>"),
        session.init(),
        passwordless.init(
            flow_type="MAGIC_LINK",
            contact_config=ContactEmailOnlyConfig(),
            email_delivery=
      ...

And finally my middleware initialization, if that helps:

Middleware(app)
CORS(
    app=app,
    origins=[
        "https://staging.<my_url>"
    ],
    supports_credentials=True,
    allow_headers=["Content-Type"] + get_all_cors_headers(),
)

hey! getting try refresh token should cause an automatic refresh on the frontend. Can i see the request headers of the API call that yields this error? You can cause this error to happen by deleting the

sAccessToken

cookie

Sure! These are the only headers I could find from the 401 error:

:authority: staging.<my_url>
:method: GET
:path: /
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
cache-control: max-age=0
cookie: sIdRefreshToken=519fc581-fdc6-40a6-ad9e-3d5245375d30; sIRTFrontend=519fc581-fdc6-40a6-ad9e-3d5245375d30; sFrontToken=eyJhdGUiOjE2NzUzOTg5NzIzODMsInVpZCI6ImIyN2YxZTc0LWFhYjEtNDcyNS1iOTI0LTIwMDQ5ZTA2ZDAwZCIsInVwIjp7fX0=
sec-ch-ua: "Not_A Brand";v="99", "Google Chrome";v="109", "Chromium";v="109"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
sec-fetch-dest: document
sec-fetch-mode: navigate
sec-fetch-site: none
sec-fetch-user: ?1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36

ok so the issue is that our frontend SDK is not intercepting the request

yes, it's the same url as apiDomain from the backend init

do you call supertokens.init before making this API call?

Hm @rp_st , it actually looks like I'm not getting any frontend logs at all, which makes me think that the API call isn't being made before the 401 error is thrown?

yea it seems like you have not called supertokens.init

this might be a dumb question, but again I'm not a frontend dev.. where am I meant to call supertokens.init for the frontend to ensure that it is called prior to the 401 error being thrown?

I ran into the same issue. I think it had something to do with the fact that we don't serve our frontend assets separately-- like your app, we template html on the server and the javascript gets served with it. If the endpoint that serves the supertokens js is itself behind auth, there are situations where it never gets a chance to run

@jarth1388 why do you redirect to the login page and not refresh the session as the docs describes?

I had some trouble getting it working, but that sounds like the correct thing to do. I was trying to make sure that a user arriving at /some_endpoint with no cookies at all got properly redirected, so I was testing by deleting all local state.

Well, they would get redirected to the refresh page (as mentioned in the docs), and refreshing would then fail (cause they have no cookies), causing them to be sent to the login page anyway. But for users who do have cookies (but just need a refresh), sending them to the login page will not refresh their session

Ok that makes sense. I will try to get the refresh workflow working again and report back

Sounds good @jarth1388 , thanks for the suggestion! I'll give getSession() a try and refresh the session on error as @rp_st mentioned

I got this working yesterday-- I had gotten a bit confused on the difference between

/refresh-session

and

/session/refresh

because I didn't keep reading the second half of that page 🤦‍♂️ . Once I got that working everything worked great!