Hi there, I’ve got a question around recipe user id usage for email verification please as I’m not sure if there is a bug in

getUser

or I just don’t understand how user id mapping is supposed to work between recipe user ids and external ids. Currently we’re mapping our users to an external id with

createUserIdMapping

after signing them up. We then verify their emails using the external id as it’s the id returned by calling

getUser

. Once the email is verified, a row is added to

emailverification_verified_emails

with the external user id as the

user_id

in the database. This works well as the email verification claim

st-ev

is

true

in the access token jwt and if I call

isEmailVerified

with the external user id converted to a recipe user id then it returns true.
The problem seems to be with

getUser

as it returns a list of

loginMethods

but the

verified

flag is false even though

isEmailVerified

returns true if I check using the same

recipeUserId

and email returned in the login method. The email verification claim for this user is

true

in the access token too. However if I change the logic to verify the email based on the supertokens user id instead, then

getUser

will return the login method

verified

as true but the email verification claim

st-ev

is false. I may be misunderstanding how the different ids are supposed to be used but it seems like

getUser

may be returning the verification status of the email login method incorrectly please?

Hey @david_61794

Yes precisely. That seems to be what is happening. Thank you very much @rp_st 🙏

@sattvikc can also help here.

Just a single login method. We're currently calling the

sendEmailVerificationEmail

with the external id as the user id and recipe user id which is probably where the issue is coming from then as you say. I believe when upgrading to the most recent version os Supertokens, we were having issues with sending the emails after passing in the recipe user id from the signup call so just went with using the external id as it appeared to be working.

so the recipeUserId is the value that determines for which userId the email verification token is going to be generated

Sure thing, in our function override for

emailPasswordSignup

we've got:

const response =
  await originalImplementation.emailPasswordSignUp(input);

await supertokens.createUserIdMapping({
  superTokensUserId: response.user.id,
  externalUserId: input.userContext.externalUserId,
});

const updatedUser = await supertokens.getUser(
  input.userContext.externalUserId,
);

// With the mapping update, the id and login methods have changed so update the response so that the session creation after this succeeds
response.user = updatedUser;
response.recipeUserId = supertokens.convertToRecipeUserId(
  input.userContext.externalUserId,
);

await EmailVerification.sendEmailVerificationEmail(
  "public",
  response.user.id,
  response.recipeUserId,
);

is the value of

updatedUser.loginMethods[0].recipeUserId

the external user ID as well? Or a UUID that we generate?

It's the same as the external user ID

right yea! Okay. So this is an issue with the core.

Thanks very much will do. I guess the expected behaviour is that the recipe user ID will always be the UUID that supertokens generates and the

user.id

will either be the external mapped id or the supertokens generated id if there is no mapped id?

no.. the recipeUserId being the external one is fine. The bug is that the email verification query that filles in the loginMethod's verified field doesn't take into account the external user id mapping!

Ah okay, thanks for clarifying 🙏 Raising the issue on

sueprtokens-core

now

perfect! thanks