Hi, @rp_st we have problem where GET /auth/user/email/verify is being called infinitely from some users. Can we get a sense why this might be happening?

Hey.

yeah.

Right. And on which screen does this happen?

we have no idea. according to logs we are collecting, user is already inside and using website normally. my feeling is that it is happening some other inactive tabs or something.

So this api is called each time SessionAuth component mounts and if the user’s email is not verified.

user's email is verified already. still it can make api calls infinitely?

Then it shouldn’t.

it is called like crazy. every 50ms or something.

Can you reproduce it though?

i couldn't reproduce on my own.

This could also happen if there is some sort of time misconf on the user’s machine

can u elaborate more about that case please?

If the user’s system time is let’s say, 5 mins ahead of the real time, then the frontend will think that it’s time to check for email verify status

so if user set local time to 5 mins ahead of server's time, it will happen definitely?

I’m guessing, but yea I think it should

i think u r right. user's time is about 7 mins ahead of server's time.

Right. So that’s about it

what can be fix in this case?

There is not much to do here at the moment.

i mean it is not seriously harmful atm but it makes it impossible to analyze logs and/or irritate other api calss.

But it’s not something we will do anything in the next few months

can i ask why this is checked periodically?

In case the user’s email is unverified offline, then the frontend will eventually get the right value

and this is called periodically even when user's email is already verified?

Yes

i see.

But you can change this behaviour

yeah, i will try to override the function u mentioned above.

This is the claim that’s used. https://github.com/supertokens/supertokens-web-js/blob/master/lib/ts/recipe/emailverification/emailVerificationClaim.ts

i personally think this can have serious consequence. not sure if this can act as DDoS or sth.

You can do this on the frontend session.init:

tsx
Session.init({
    override: {
        functions: (oI) => {
            return {
                ...oI,
                getGlobalClaimValidators: function (input) {
                    // we first remove the default email verification validator
                    input.claimValidatorsAddedByOtherRecipes = input.claimValidatorsAddedByOtherRecipes.filter((validator) => {
                        return validator.id !== EmailVerification.EmailVerificationClaim.key;
                    })

                    // then we add the validator again with the new time values
                    // with checking for every 15 mins.
                    input.claimValidatorsAddedByOtherRecipes.push(EmailVerification.EmailVerificationClaim.validators.isVerified(undefined, 15 * 60));
                    return [...input.claimValidatorsAddedByOtherRecipes];
                }
            }
        }
    }
})

hi, @rp_st what if we want to change logic of EmailVerificationClaim?

You could remove the validator entirely and make your own if you want

i couldn't create it because of these construct params. especially getRecipeImpl.

export class EmailVerificationClaimClass extends BooleanClaim {
    constructor(
        getRecipeImpl: () => RecipeInterface,
        updateContextOnIsVerifiedFalse?: (userContext: any) => void | Promise<void>
    ) {
        super({
            id: "st-ev",
            refresh: async (userContext) => {
                await getRecipeImpl().isEmailVerified({
                    userContext,
                });
            },
        });

you want to create a custom validator right?

yeah

on the frontend or backend?

on the frontend.

and what would it do that's custom?

i am gonna calculate timediff between client and server and use it to avoid this situation.

right. So i this case, you can create your own logic like this:

tsx
let myCustomValidator = (refetchTimeOnFalseInSeconds?: number | undefined, maxAgeInSeconds?: number | undefined) => {
    let isVerifiedValidator = EmailVerification.EmailVerificationClaim.validators.isVerified(refetchTimeOnFalseInSeconds, maxAgeInSeconds);

    return {
        ...isVerifiedValidator,
        shouldRefresh: (accessTokenPayload, userContext) => {
            // TODO: custom logic here.
            // See our default implementation of this function here: 
            // https://github.com/supertokens/supertokens-web-js/blob/master/lib/ts/recipe/emailverification/emailVerificationClaim.ts#L26
            return false;
        },
    }
}

And then, iun the previous code snippet i sent (overriding getGlobalClaimValidators), you can add

myCustomValidator

to the array

is there any way to have access to recipe object outside of library?

you can use the EmailVerfiication receipe functions directly. It's the same thing

great, thanks.