https://supertokens.com/
Join Discord
Hi! I'm trying to access the verify email page, but it doesn't seem to exist. What's the setup here?...
# support-questions-legacy
c
Hi! I'm trying to access the verify email page, but it doesn't seem to exist. What's the setup here? Very few docs on this too.
r
Hey! Can I see the supertokens.init on the frontend?
c
Here you go:
I tried to init EmailVerification but couldn't find the right export
r
This seems fine. The email verification screen would be on {websiteBasePath}/email-verify
And is only applicable for third party logins
If the email from the third party site says the email is not verified.
So if you are not logged in, or email is verified already, the email verification screen will redirect you
If you want to force show the email verification page even if the email is verified, you can do this on the frontend:
Copy code
ThirdPartyPasswordless.init({
    /* Your other config */
    override: {
        emailVerification: {
            functions: (oI) => {
                return {
                    ...oI,
                    isEmailVerified: async function (input) {
                        return {
                            status: "OK",
                            fetchResponse: new Response(),
                            isVerified: false
                        }
                    }
                }
            }
        }
    }
})
This way, you are telling the email verification component that the email is not verified by overriding the 
isEmailVerified
component.
c
so it simply does not respond when the email is verified?
r
If email is verified, and you don’t override the function as shown above, then it will call the API, which will return that the email is verified. And then the UI will not load the email verification screen.
Overriding it like how I showed you above, prevents an api call and tells the Ui the email is not verified. This way, you can see the email verification screen. I assume you wanna see it for development purposes
c
I mainly want to find which URL I should use 😅
Given settings like this, which URL leads to the verify email page?
r
/auth/email-verify
c
API domain or web domain?
I'll guess web domain since you wanted to see the frontend init
so localhost:8080/login/email-verify?
r
Yup.
c
Okay, thanks!
One more issue, there are no entries in the emailverification_verified_emails table
but the email verification view still does not show
r
For passwordless logins, there will be no entry, but for third party, there should be
c
(leads to 404 page in the app)
the verified emails table is completely separate from the specific auth recipe though?
r
yup.
c
I don't really get how the verification feature works then
r
On social login, if the provider says that the email is verified, it will put it in the verified table. For passwordless login, it doesn’t use the email verification table as it assumes that all email are verified.
c
ah okay
r
On the frontend, whenever we do session checking (for example in the auth guard), we check if the email is verified or not. If not, we redirect to the email verification screen
For passwordless users, they email is always considered as verified
c
It's for passwordless users that I WANT to show the email verification flow
if the user uses a phone number to sign in, I want to be able to separately verify their email when they set it in their profile
do I just need to handle this completely manually?
r
Ah right. I see.
For this, you would have to override the thirdpartypasswordless recipe on the backend like this: https://gist.github.com/rishabhpoddar/7de46de8135cc4e134ead83321c7451b Also note that for this to work, we have also initialise 
EmailVerification
in the recipeList on the backend. I know that this can be slightly confusing, but in short, the thirdpartypasswordless recipe has its own instance of the emailverification recipe inside it which has been modified to treat all passwordless users as if their email is verified. So to hack around it, we create our own 
EmailVerification
recipe instance and use that. We will make this easier in a few weeks, but for now, you can try this.
c
great, thanks! I'll try
It goes into a redirect loop from the verify-email endpoint in the frontend
Do I need any frontend setup?
r
Can you describe the redirect loop? From which page to which page?
c
I can only see the verify-email path but it refreshes in a loop
as if it's trying to redirect to my app but gets sent right back to the email verification screen, then back to the app, etc
r
hmm. Are you using in a component that's shown on that route?
c
yes
I set it up according to the recipe setup without react-router
r
Right. So are you wrapping your whole app with 
ThirdPartyPasswordlessAuth
?
or just a specific component (like a header or something) in that?
c
Actually I have it twice. The whole app is wrapped with that but requireAuth=false, then protected routes are wrapped again with requireAuth=true
r
i see. So you should remove the whole app wrapping thing. That causes issues like you are seeing now. But we are working on fixiing it soon enough.
c
okay!
r
And instead, use 
ThirdPartyPasswordlessAuth
only for the specific routes you want to check for session in
c
okay yeah, that was the reason I had it. I need to check sessions even though the route doesn't require auth
r
So for that, you can use 
<SessionAuth requireAuth={false}>...</SessionAuth>
wrapper instead
import {SessionAuth} from "supertokens-auth-react/recipe/session"
c
okay, I'll try! 😄 thanks
Do I need to provide the new EmailVerification recipe a function for sending emails?
It seems so
r
It will be default send it using our APIs, but if you had a custom way of sending an email, then you will have to provide that as well to the emailverification recipe.
c
The docs said to implement a custom email sending function for the thirdpartypasswordless recipe
I can reuse it for the email verification though 😄
r
Yeaa. You should reuse it.
Well, the docs are a little sparse when it comes to explaining how to do customisations like the one you are looking for.
c
Email OTP login works, but the verification email never arrives. No logging from the 
createAndSendCustomEmail
function either 🤔
they use pretty much the same sending function, but with a different email template
r
Hmmm.
c
I also noticed the 
createAndSendCustomEmail
signature is different between the ThirdpartyPasswordless and the emailverification recipe
r
Can you add logs to the email verification override that functions from the GitHub gist? To see what’s happening?
c
okay I'll try!
yeah they log, the user object looks good
and it creates new email verification tokens in the DB each time I click "resend"
r
But the function. You provided for actually sending the email doesn’t get called?
c
yeah
createAndSendCustomEmail does not log, neither does the getEmailForUserId
r
the 
getEmailForUserId
not logging is fine. Can I see how you have given 
sendVerifyEmail
to the thirdpartypasswordless recipe?
c
I haven't, it's a separate function for logging in
r
Can i see the full init for thirdpartypasswordless recipe? In text form please
c
r
Can you change the thirdpartypasswordless init to include a field for 
emailVerificationFeature
like so:
Copy code
ts
ThirdPartyPasswordless.init({
    flowType: 'USER_INPUT_CODE_AND_MAGIC_LINK',
    contactMethod: 'EMAIL_OR_PHONE',
    providers: [...],
    createAndSendCustomEmail: sendAuthEmail,
    createAndSendCustomTextMessage: sendAuthSms,
    emailVerificationFeature: {
        createAndSendCustomEmail: sendVerifyEmail // maybe the types don't match up, but you need to provide a function here to send an email verification email.
    }
    override: {
      ...
    }
  }),
And the emailverification.init can just be:
Copy code
EmailVerification.init({
        getEmailForUserId: async (userId) => {
          let user = await ThirdPartyPasswordless.getUserById(userId);

          if (user?.email) {
            return user.email;
          }

          throw new Error('Should never come here');
        },
      }),
That is, we remove the 
createAndSendCustomEmail
from there.
c
alright, I'll try!
can I just return undefined from getEmailForUserId or does it have to throw if there is no email?
r
has to throw, since the output of it must be a string
c
okay! I'll keep the throw then
r
but it should never come there anyway - unless there is a bug in the code somewhere
c
it works! 😄
r
oh great!
what's strange is, even if you don't provide that, it should have still sent an email to the email ID - did you not get any email?
cause by default, it sends an email using our api.supertokens.com API layer
c
yeah, no email :<
is that a new thing?
r
hmmmm. No it's not a new thing
hey @CaptainPhoton one more change will be required. After doing supertokens.init on the backend, you want to do the following:
Copy code
let ThirdPartyPasswordlessRaw = require("supertokens-node/lib/build/recipe/thirdpartypasswordless/recipe").default;

ThirdPartyPasswordlessRaw.getInstanceOrThrowError().emailVerificationRecipe.config.getEmailForUserId = async (userId) => {
    let user = await ThirdPartyPasswordless.getUserById(userId);
    if (user !== undefined && user.email !== undefined) {
        return user.email;
    }
    return "";
};
Otherwise the email that's send to your callback to send the email is an incorrect one.
c
it did work without 🤔
the email came, I clicked the link, it said the email was successfully verified
r
Hmm. That’s weird. The email in the callback you provided should have been some random hard coded one. Not the actual user’s email
c
dunno what to say... it works 😄
r
Haha well. If you run into any issue, lmk. Strange
Can you print out the arguments given to sendVerifyEmail?
@CaptainPhoton
c
not working on it atm but I'll tell you when I'm back at it 😄
r
Cool
c
r
ah right. Yea this makes sense. Sorry i was confused about something.
c
okay 😄 it still works
r
That being said, you should still do what i said here: https://discord.com/channels/603466164219281420/987701400433725440/988016274443489300 We are working on a release in which you no longer need to do that, but until then, please add it. Otherwise it may cause unexpected issues.
c
okay... what issues?
r
for example, the email in the email verification table may not be the same as the user's email, even though it has their user ID.
c
oof, okay, I'll add it 😄 I currently only have one user here on my local instance
r
ah okay
PreviousNext
Powered by

SuperTokens.com

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

Powered by