Quick clarification -- I'm using the Session and Email Verification recipes on the back and ST-website on the front (plain JS). When the user gets an email link to verify their email, I need to code in myself a way to take the token from the url and POST it to my backend through ST's exposed endpoint (

{{apiBasePath}}/auth/user/email/verify

by default)? Or am I misunderstanding and ST-website should be able to process that handshake for me (after the user clicks the verify link)?

Hi, Yes that is correct, with the website sdk you need to read from the url and make a network call yourself

Thanks, I came up with another question: I'm overriding the backend functions of the email verification recipe, I want to keep the default functionality of verifying an email, however I don't want the ST schema to keep a list of verified users and instead I have a bool for each user in my own schema. What I've done so far is override the function and replicate the behaviour of the original method with several POSTs to the ST CDI, and then added in my own desired behaviour (sending a POST to remove the user from the ST schema's verified users table) Long story short, is there an option for a backend API hook where I can retain the original behaviour and also add my own behaviour on top?

Can you send me the snippet of how you are doing that at the moment?

Right so you could do it this way instead

override: {
    functions(originalImpl) {
        return {
            ...originalImpl,
            ...
            async verifyEmailUsingToken(input) {
                // Do your custom logic before ST here

                // This will let ST do its logic including adding to the schema
                const STResult = await originalImpl.verifyEmailUsingToken(input);

                // Remove the verified email from ST or any other ST schema changes here
                return STResult;
            },
            ...
        }
    }
}

I thought about that but I assumed the original implementation is overridden as soon as write the call to the function

So think about it this way

yeah I wasn't sure about the last part, I thought calling STResult would just be a recursion... good to know it isn't

Yes, we pass it on to you when you add your overrides

Thanks, finally are there plans to abstract the password reset flow into its own recipe (similarly to how Email Verification was abstracted from the EmailPassword recipe)?

Not at the moment no, the idea of email verification was because multiple recipes needed the same functionality. Reset password however is only applicable to email password so we dont plan on abstracting it out

yes exactly

Well one way I can think of to accommodate that is to initialise EmailPassword on the backend (this also initialises email verification) and then simply continue to call the APIs manually when creating a user etc

I initially was going to do that, but the complexity of the overrides was making it more effort than to just implement it myself

Right, yeah I cant think of a way to do this without adding that complexity

Yeah no worries, I can understand it being a very small use case

Btw instead of manually calling the CDI API to remove the verified email, you could simply override the

verifyEmailUsingToken

api (similar to how you are doing function overrides) to simply call the ST version first and then call

revokeEmailVerificationTokens

before returning. That way everytime the CDI marks an email as verified it will immediately be removed

Does

revokeEmailVerificationTokens

call

unverifyUser

? Not quite sure how it would otherwise remove the a verified user from ST?

It calls the

"/recipe/user/email/verify/token/remove"

endpoint

Yeah I realised its not exactly elegant to start shooting axios requests at the CDI inside an override

It shouldnt be a problem, in essence it would just be about firing one API call after another