Hi there, I’ve got a question around recipe user id usage for email verification please as I’m not s...
d

david_61794

about 2 years ago
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?
Hi there! Here's the issue I'm facing. I'm at the step where I've deployed FastAPI to an AWS Lambda...
a

adyus3380

about 3 years ago
Hi there! Here's the issue I'm facing. I'm at the step where I've deployed FastAPI to an AWS Lambda function via Mangum, with Supertokens successfully running (returns hello from /hello), the Lambda function accessing the API database, and the frontend accessing the API. All of these are tested. Unfortunately, I get a cryptic error in the post-signup handler:
response = await api_implementation.sign_up_post(
  File \"/var/task/app/users/utils.py\", line 93, in sign_up_post
    response = await original_sign_up_post(form_fields, api_options, user_context)
  File \"/var/lang/lib/python3.9/site-packages/supertokens_python/recipe/emailpassword/api/implementation.py\", line 199, in sign_up_post
    result = await api_options.recipe_implementation.sign_up(
  File \"/var/lang/lib/python3.9/site-packages/supertokens_python/recipe/emailpassword/recipe_implementation.py\", line 123, in sign_up
    response = await self.querier.send_post_request(
  File \"/var/lang/lib/python3.9/site-packages/supertokens_python/querier.py\", line 167, in send_post_request
    return await self.__send_request_helper(path, \"POST\", f, len(self.__hosts))
  File \"/var/lang/lib/python3.9/site-packages/supertokens_python/querier.py\", line 246, in __send_request_helper
    raise_general_exception(e)
  File \"/var/lang/lib/python3.9/site-packages/supertokens_python/exceptions.py\", line 25, in raise_general_exception
    raise GeneralError(msg) from None
supertokens_python.exceptions.GeneralError
Now, I've tried running the same FastAPI locally (sans Lambda), passing the same Supertokens instance and same API database in production (just the API running locally in uvicorn). I was able to successfully create a new user! Then, I was able to successfully sign in as that user via the frontend hitting the Lambda API 🤯 This tells me that the Lambda function does have access to the Supertokens deployment for signin functions, but mysteriously fails for signup.