now i just have to figure out how to get email to the front-end so i can display that to the user.

that's exactly the recommended way of doing it 🙂

We don't store that on the frontend by default, but there are a few options

You could add it to the access token payload and use that through

useSessionContext

, but this will get transmitted with every request. (https://supertokens.io/docs/emailpassword/common-customizations/user-roles/assigning-session-roles)

You also get this info when login succeeds so you could store this locally after a login succeeds(https://supertokens.io/docs/emailpassword/common-customizations/handling-signin-success#1-on-the-frontend). If you go with this I'd recommend tying the stored info the the session id, so the if something goes wrong you don't display the wrong email)

Also, you can just add an API endpoint and store the result in memory. Most apps fetch some info about the current user anyway, so you could do it at the same time.

👍

Not necessarily, check out our "session management only" recipe https://supertokens.io/docs/session/quick-setup/frontend You can define your own auth/routes and validate the session on multiple node servers if they have access to the cookie.

Not out of the box. You can implement this by changing the password of the user (

updateEmailOrPassword

), then revoking all their sessions (

revokeAllSessionsForUser

)

Hi, you can do this by overriding

signUpPOST

. Something like this should work:

EmailPassword.init({
        override: {
            apis: (originalImplementation) => ({
                ...originalImplementation,
                signUpPOST: async function (input) {
                    const email = input.formFields.find((f) => f.id === "email").value;
                    const password = input.formFields.find((f) => f.id === "password").value;

                    return EmailPassword.signUp(email, password);
                },
            }),
        },
        // ...
    },

thank you porcellus, i have another question

message has been deleted

i want to secure my routes with this method from the session recipe under common customizations

the redirect function i provide just needs to return a react-router-dom redirect component correct?

No, it's a

() => void

function, it needs to do the redirect itself (or do nothing, show a popup, whatever suits your needs)

once i have a user signed up via third party provider, how do i get their email, name, etc?

@User you can get the access token sent by the third party provider like this: https://supertokens.io/docs/thirdpartyemailpassword/post-login/getting-provider-access-token Then you can query the provider and get any info you like.

I have an app where the user, after logging in, can generate a token with a customizable lifetime (30 days, 60 days, Never) It is similar to generating a personal access token in github. The user should be able to revoke the token whenever required. This token will be used by the user to call a set of apis. How would I go about implementing this? Does supertokens support this?

Yes. We do support this. The tokens that would be issued are JWTs. You can enable JWT support from our session recipe (in session.init). You can then create a new JWT (using the session recipe) with custom payload and custom lifetime in your API post session verification. You can return this JWT to the user as their personal access token.

The only issue with this is that you can’t revoke them by default. In order to do that, you can store a custom ID in the JWT, and also in your db. During JWT verification, you can check if that custom ID still exists in the db.

However, if you do that, you can also send just the custom ID as there access token anyway.. so it kind of beats the purpose of making a JWT, unless you want to use the JWT as also a way to store some custom payload info

@User Thank you for the response. The token will not need to store any custom payload other than a way to identify the user. Like github, I also want to alert the user via an email when his token is about to expire.

I see. So then it would make more sense to just handle this part yourself without supertokens, as we don’t add any value to this yet.

Thank you @User. Any advice how to go about it and what security considerations to factor in.

@User - Make sure the access token is generated with enough entropy and is long enough (>= 32 chars should be enough). You can use something equivalent to SecureRandom in Java (https://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html) - You can store the associated userId and lifetime in your db against the token. Do not send these to the frontend. - From a performance point of view, you can cache this info and query the cache on each API call that uses the access token. - Send this token as an Authentication bearer token in API requests (see https://swagger.io/docs/specification/authentication/bearer-authentication/). - Make sure to check if the lifetime of the token has expired each time you authenticate the token from the db. - Set up a cronjob to remove expired tokens.

Thank you @User

Supertoken 🤝 Invide. I'm in both sides !