more like I have to clear the cookies and login again if it expires xD

and unless the cookies are removed, the try again errors keep showing up

> unless the cookies are removed, the try again errors keep showing up You can all the refresh API with the same set of cookies and it will update the cookies automatically on Postman. The refresh API will be on {apiDomain}{apiBasePath}/session/refresh POST: https://github.com/supertokens/frontend-driver-interface/blob/master/v1.7.1.md#url-apibasepathsessionrefresh Alternatively, for dev env, you can set the access & refresh token's time to be really high so that you don't run into the issue of the cookies expiring in the first place: https://supertokens.io/recipe-redirect?to=common-customizations/sessions/change-session-timeout

But yea.. do you have any ideas on how we can make that easier though?

haha, unless these http clients have hooks that can react to certain responses on certain endpoints, this will be manual 😂

hahaa.. yeaaa :((

I guess you can set the session timeout REALLY high

and that would more of less remove this annoyance.

it's not really a deal breaker and it's expected behavior as per limitations of the tools being used so yea, it's either of the two as you mentioned, manually refresh by hitting the refresh endpoints or setting a really high expiry time

Hmm. Fair enough!

regardless, I think the defaults are fine, it's just that when we signout, we need to keep this in mind xD

It worked all good! Just updated on our local env. Thanks a lot!

forgot to ask earlier @User is there a way to not enforce the unique constraint on the email aside from removing it manually? use case is the third party accounts have the same email but user wants to connect all of them on our app

I think that’s a typo in the docs. There shouldn’t be a UNIQUE there.. let me check

Yes. The email column is not unique. The doc is incorrect. I’ll correct it. Thanks for pointing it out!

aight, awesome! @User

been wondering, if I write some data to the

req.session

object, where do these get persisted? in-memory?

u mean using

updateSessionData

or

updateJWTPayload

functions?

no, like imagine if a project use https://www.npmjs.com/package/express-session#reqsession

those have connectors based on what you setup right, by default it's in-memory if not provided

oh right.. with express-session, it gets saved in the db

does supertoken do anything with the session object?

or only the methods from the

SessionContainer

interface matters for supertoken?

> only the methods from the SessionContainer interface matters for supertoken? This.

so if I attach something to

req.session

when using

express-session

, then that's on the realm of the said lib and supertokens does not interfere with it, correct?

Yes. those.

and if I don't use

express-session

but try to attach something to the

req.session

object, since no middleware persists the "session object" itself, it just gets disposed after the middleware pipeline

yes

and again, supertokens just simply provides methods to the session object

yes