https://supertokens.com/ logo
#support-questions
Title
# support-questions
n

Naf

06/18/2022, 8:23 PM
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)?
n

nkshah2

06/19/2022, 3:41 AM
Hi, Yes that is correct, with the website sdk you need to read from the url and make a network call yourself
n

Naf

06/19/2022, 9:42 AM
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?
n

nkshah2

06/20/2022, 7:57 AM
Can you send me the snippet of how you are doing that at the moment?
Also im not sure I understood your question. Are you saying you want to have custom logic and then simply allow ST to proceed as it normally would? Or do you want custom logic and then have ST do its own logic except for the part of adding users to its schema?
The above is how I've handled it so far, I was wondering if there is a way to have ST do its own logic, then add some custom logic on top
where "custom logic" also includes telling the ST core to not add verified users to its own schema (because I'm already recording that in my schema)
n

nkshah2

06/20/2022, 9:08 AM
Right so you could do it this way instead
Copy code
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;
            },
            ...
        }
    }
}
originalImpl
allows you to call any of the ST SDK functions for that recipe so you dont have to duplicate the SDK logic yourself
Then before or after calling the ST SDK function you can add any custom logic/cleanup logic you need before returning from the function
n

Naf

06/20/2022, 9:10 AM
I thought about that but I assumed the original implementation is overridden as soon as write the call to the function
Does ST keep the original method lying around then for these situations?
n

nkshah2

06/20/2022, 9:10 AM
So think about it this way
When you need to call a function you will most likely do
STEmailVerification.someFunction
. Now when you override
someFunction
, that line of code will execute your version of the function instead of the SDKs But we also give you access to the original set of functions that the SDK implements (via originalImpl) should you need them
So in your overrides, any time you refer to
originalImpl.someFunction
it always refers to the SuperTokens version of that function
n

Naf

06/20/2022, 9:12 AM
yeah I wasn't sure about the last part, I thought calling STResult would just be a recursion... good to know it isn't
n

nkshah2

06/20/2022, 9:12 AM
Yes, we pass it on to you when you add your overrides
Yep its a little confusing at the start to be fair
n

Naf

06/20/2022, 9:14 AM
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)?
n

nkshah2

06/20/2022, 9:15 AM
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
Out of curiosity, do you have a use case where it would make sense?
Oh I suppose you want your own email password auth? and just use email verification and password reset from ST
n

Naf

06/20/2022, 9:16 AM
yes exactly
n

nkshah2

06/20/2022, 9:17 AM
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
And then override the functions of email password and email verification to do your logic instead of ST
That way you still maintain full control on email password auth and then levy ST for the rest
This is from the top of my head though so not sure if it will fully work
n

Naf

06/20/2022, 9:18 AM
I initially was going to do that, but the complexity of the overrides was making it more effort than to just implement it myself
In the end I think the biggest issue was it relies on users being persisted into the ST schema
which is something I don't want
n

nkshah2

06/20/2022, 9:20 AM
Right, yeah I cant think of a way to do this without adding that complexity
Ill bring it up with the team though and see if theres enough reason for us to abstract it out
But I dont think that will happen anytime soon
n

Naf

06/20/2022, 9:21 AM
Yeah no worries, I can understand it being a very small use case
It's because this app I'm planning requires me to verify the domains of users' emails, so I want to handle all of that myself
otherwise I'd just go and use the full email/pass recipe
n

nkshah2

06/20/2022, 9:24 AM
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
And you wont have to call the API manually each time
You can mix and match with our functions and get what you want working in a simpler way
Most CDI API calls have a function associated with them so you shouldnt need to call them manually
n

Naf

06/20/2022, 9:35 AM
Does
revokeEmailVerificationTokens
call
unverifyUser
? Not quite sure how it would otherwise remove the a verified user from ST?
n

nkshah2

06/20/2022, 9:35 AM
It calls the
"/recipe/user/email/verify/token/remove"
endpoint
Which you are currently calling manually
Oh I see what you mean
Yeah youd call both functions instead of just revoke
Using the functions instead of APIs is a better idea though, future changes to the API routes wont need manual changes from your end
n

Naf

06/20/2022, 9:38 AM
Yeah I realised its not exactly elegant to start shooting axios requests at the CDI inside an override
n

nkshah2

06/20/2022, 9:41 AM
It shouldnt be a problem, in essence it would just be about firing one API call after another
2 Views