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

SuperTokens.com

Hi SuperTokens Team, it looks like that the upgrade from v12.1.6 to v13.02 (v0.4.1 to v0.5) cannot be done without migration actions. I changed both versions and get into trouble cause some headers will be set differently as expected (does the default transfer method change?). Is there a documentation somewhere which tackles the migration to v13, as the release notes doesn't say anything about it?

hey <@1055402344419967047> 

The default transfer method doesn't change, and the migration should work fine if you have updated both the frontend and backend. But we have had other people complain about it too.

Can you tell me the observed behaviour please?

I updated both versions, frontend and backend.
I noticed the following:
For our E2E test (Testcafe) we are calling the auth/signin endpoint to retrieve the auth cookies.
We did that by getting the response header value by the key 'set-cookie'. This header key doesn't exist anymore (it's not the best option, I know, but it worked with V12.1.6).

Hmmm.  That’s strange. Can you print out the response headers?

I mean the sign in api response headers *

```headers {
  'cross-origin-opener-policy': 'same-origin',
  'cross-origin-resource-policy': 'same-origin',
  'x-dns-prefetch-control': 'off',
  'x-frame-options': 'SAMEORIGIN',
  'strict-transport-security': 'max-age=15552000; includeSubDomains',
  'x-download-options': 'noopen',
  'x-content-type-options': 'nosniff',
  'origin-agent-cluster': '?1',
  'x-permitted-cross-domain-policies': 'none',
  'referrer-policy': 'no-referrer',
  'x-xss-protection': '0',
  vary: 'Origin',
  'access-control-allow-credentials': 'true',
  'front-token': 'eyJ1.....xxxxxxx',
  'access-control-expose-headers': 'front-token, st-access-token, st-refresh-token',
  'st-access-token': 'def.....xxxx',
  'st-refresh-token': 'sp8zA... xxxx7f.V2',
  'content-type': 'application/json; charset=utf-8',
  'content-length': '127',
  etag: 'W/"7f-rjhH0uYEmddslJz9sRtpf8/dyTo"',
  date: 'Wed, 15 Feb 2023 15:27:55 GMT',
  connection: 'close'
}
```

You need to set the st-auth-mode header in the request to cookies

Our web frontend SDK does this on its own

But I think you are not using that for e2e tests

Ah, exactly. Calling the auth/signin endpoint via the website itself returns the "set-cookie" header keys. 
So setting the ```st-auth-mode header``` should do the trick.

Yes. You want to set the value of it to “cookie”