What would you like to have happen in case someone doesn't provide their email and has forgotten their password?

Just allowing usernames for login just like any big social media apps out there

No no, what I meant was email password is required as it is now but usernames could be "enabled" with just a boolean and one can sign in with it, prob the sign up would have an additional field right away for usernames. That way, we still get emails for resetting passwords while being able to sign in with usernames

Ahhhh ok. Makes sense.

And then the user can sign in with a username or their email right

idk about "or" but if they don't provide emails, they lose a subset of features

So for now, you can still use most of the emailpassword function we provide. You would need a mapping of username email and if someone signs in with their username, you can fetch their email and use EmailPassword.signIn()

So I was thinking more of an "and"

Oh nvm, you said "sign in"

Thought sign up XD

hahah yea..

Aight, thanks for confirming

That map should actually be username email

so really you only need a username userId mapping, and then you can use our functions to get their email from the userId

this way, you have to do lesser work when implementing operations like update email

Yea, was implied but yes, it's the plan xD thanks! Session management is really smooth so far btw from our initial prototypes, really nice to work with

Thanks!! :)) Our initial start was sessions only, and then we expanded to auth in general.. so we have spent way more time getting sessions to work!

Not sure if it's available for it but is there an indefinite way to set the session? Or is the JWT expiration our limitation?

something like as long as the cookie that's set indefinitely exists, the token can manage rotating themselves or something

So you can set the refresh token's lifetime to be very high and then as long as the user is active during that time, they will not be logged out (it's a rolling window style expiration)

so if you set it to 100 days, and the user sees the site on the 99th day, their session will last another 100 days

or you could set the session to expire in years even (which is as good as infinite)

oh awesome, default is 100 days right? that's plenty, guess that's one concern heavylifted already by this awesome tech!

yes.

and the good part is that even if the refresh token is 100 days, but the access token is say 1 day, the lifetime of both of these tokens is effectively 1 day assuming that the user is active.

would it be possible to add an environment variable option where we can set a prefix on the table names generated by supertokens? I'd like to basically namespace them if both app and supertokens share the same db, currently just renaming all tables to achieve this

Yea! That would be possible.. Actually, I think that's a better option to provide than renaming all tables one by one. So maybe we will give only that as an option!

Neat!

Will do this in the next version release (3.4) - which will also contain an update to use the latest JDK

Also, an option to just pass a full connection string to the db where that takes priority, if not set then it looks on the individual fields