i'm trying to describe the scenario

I've been looking into an interesting problem over the past couple of days. Here is the scenario: Our front end client is pointing to our dev environment. The user signs in and we get back the sFrontToken and the sIRTFrontend token When the web app tries to logout using our api's logout endpoint, the server responds with a 440 and the request fails. Eventually i went into the supertokens db in our dev environment and cleared all the records in the session_info table and re-ran the steps mentioned above. This time we got a successful response

Screenshot 1 highlights the cookies I get back when I'm pointing our web app to our dev environment Screenshot 2 highlights the cookies I get back when I point our web app to my local environment

What i'm trying to understand is: 1. how did we get to a state where our logout requests would get a 440 (token expired response) eventhough we logged in only seconds earlier 2. Why is there a difference in the cookies i'm seeing when I point our web app to our dev environment vs. pointing it to our local environment

could it be anything to do with the 'SameSite' value? i'm not sure why i can't see the HTTP Only cookies when working against dev Maybe I'm missing something in my understanding of how cookies work 🤔

Here is a copy of the init config used for our api:

superTokens.init({
  supertokens:{
    connectionURI: "http://localhost:3567",
  },
  appInfo: {
    appName: 'My API',
    apiDomain: process.env.API_DOMAIN,
    websiteDomain: process.env.WEBSITE_DOMAIN
  },
  recipeList: [
    Session.init({
      sessionExpiredStatusCode: 440,
      disableDefaultImplementation: false,
  }) // initializes session features
  ]
});

On the server, I've made WEBSITE_DOMAIN http://localhost:8080 (my assumption here is that this url would represent my web app running locally)

What happens if the websiteDomain does not match the origin of the request? how does the ST lib use the

apiDomain

and the

websiteDomain

? from what i can tell, the docker image on my local is the same as the docker image in our dev enivronment. I've also made sure that the latest api source code has been pulled onto our dev environment

> how did we get to a state where our logout requests would get a 440 (token expired response) eventhough we logged in only seconds earlier The most common reason for this is some misconfiguration or some cookies that were left from before after which there was a config change.. > Why is there a difference in the cookies i'm seeing when I point our web app to our dev environment vs. pointing it to our local environment In local env, the API domain is also localhost. This means the access, refresh tokens will be visible. In your dev env, the API is something else and the access and refresh token will be attached to that domain (and not localhost). So if you navigate your API domain on the browser, you will see the access token. > What happens if the websiteDomain does not match the origin of the request? Can you give me specific values for what you have so I can answer.. otherwise there are too many possibilities. > how does the ST lib use the apiDomain and the websiteDomain? For sessions, the websiteDomain is used for sFrontToken, sAntiCsrf and sIRTFrontend tokens. This is so that the JS running on your website can read these values. The apiDomain is use to attach httpOnly access and refresh tokens. ----------------- - You can remove

disableDefaultImplementation: false

as that is the default anyway. - I suggest upgrading to supertokens-node

3.4.2

and the latest version of supertokens-core since those handle a lot of session related configs automatically. (Though if you are not facing any issues, you don't need to)

@User ^

Hey @User when I make a POST request to my server that uses

FormData

, the token isn't refreshed automatically

Yea. FormData will not refresh since it’s sent by the browser. You need to send the request using JavaScript that you write.

Hmmm how can I then submit a file to the server without using FormData?

So normally for file upload, you should first fetch the destination URL from an API which will do session verification, and then use form data to upload that file on that URL. The upload should not require a session verification since the URL should be random.

Alternatively you can use https://stackoverflow.com/a/43014086

So basically create an endpoint to call for session verification, call the endpoint, and then upload the file?

See the stack overflow answer above. That can help with file upload via axios

But I still have to call the session verification separately, even if I use axios right?

I appreciate the breakdown, thank you

@User you need to create an API on the backend to handle the file upload. In that API, you need to use the function we provide for session verification.

Thanks! I figured that part out 🙂

How do I add data to the session?

Do you want to add data immediately on login / sign up or in another thats called after login/sign up?

on login/signup

And are you using supertokens login / sign up UI? Or your own?

I've set

disableDefaultImplementation

to true

But I'm still using the login/signup UI

So you are calling the createNewSession function yourself?

Not atm

@User , if you want to access the userId from the frontend post sign in / up, then you can access it as mentioned here: https://supertokens.io/docs/emailpassword/common-customizations/sessions/user-information-front-end