https://supertokens.com/ logo
Join Discord
Powered by
Hi I am using the HTTP-API (Flutter Project) and h...
# support-questions-legacy
v
Hi I am using the HTTP-API (Flutter Project) and have a problem with the email-verification: I call the https:///auth/user/email/verify/token Endpoint and get back 
{"status":"EMAIL_ALREADY_VERIFIED_ERROR"}
. But if I refresh the Sesseion afterwards (https:///auth/session/refresh), the FrontToken still has the verification set to false:
Copy code
json
{
  "up": {
    "st-ev": {
      "v": false
    }
  }
}
If I use the Server side api (python) to call 
is_email_verified
directly, i also get verified=
True
. When does supertokens change the value in the FrontToken? (I noticed that the Token did refresh after I switched to a different user and back in the same window)
r
Hey @VonMorgen which versions of the SDKs are you using?
The value in fronttoken changes whenever the access token payload changes.
So in this case, it would happen if the users email is marked as unverified somehow
v
i am using supertokens-python 0.11.2
r
The value of fronttoken also is set during refresh. Based on the access token payload in the database
What’s the access token payload in the access token when this happens? You can see that if you put the access token in JWT.io
v
Copy code
json
{
  "ate": 1667583850549,
  "uid": "166e07a4-50ea-4b56-9f80-8adbfb415fa8",
  "up": {
    "st-ev": {
      "t": 1667576931314,
      "v": false
    },
    "supabase_token": "<supabase_token>"
  }
}
r
Hmm. So the access token payload didn’t update in the db even though the claim was saying true before the refresh?
What happens when you call the is email verified api with the session?
Does the payload get set to true after that api call?
v
the GET users/email/verify returns:
Copy code
json
{
    "status": "OK",
    "isVerified": true
}
yeah, now the refreshed token also contains 
"v":true
r
And now if you call the refresh api, what’s the value of the access token?
v
Copy code
json
{
  "ate": 1667584272679,
  "uid": "166e07a4-50ea-4b56-9f80-8adbfb415fa8",
  "up": {
    "st-ev": {
      "t": 1667580595258,
      "v": true
    },
    "supabase_token": "..."
  }
}
r
Right. So this works
I wonder why initially it was false post refresh.
Can you replicate that issue?
v
hm, no. I tried both with my app code and with postman, but both times after the "verify Email"-Request, all tokens had the value correctly set to true
r
Hmmmm
v
the only thing i did differently is that i logged in with a different user before the issue occurred
i will try that again
r
I didn’t understand the scenario
Hey @VonMorgen were you able to replicate the issue?
v
yeah, finally: 0. unverify user (via backend) 1. clear cookies (in browser) 2. clear cookies (in postman) 3. sign in via postman => verified= false 4. send verification email (in postman) 5. open link in browser and verify email there 6. check via server side sdk => verified: true 7. refresh (in postman): => verified: false (<- expected true) 8. get verify email (in postman): => verified: true 9. refresh (in postman): => verified: true
r
I see. So the session refresh doesn’t update the claims. It only creates new tokens.
In step 5, do you open the link on the same browser as the one in which the session exists? And if yes, once the api is called to verify the session, does the session claim gets update to verified: true?
Also, the refresh in postman is for another session right?
I mean postman has its own session and the browser has its own session?
v
no, i cleared all cookies in the browser so that it calls the verify email endpoint without a session
r
I see. In that case, this is the expected behaviour. A call to the API for is session verified will update the claims in the session (as you had seen before)
We should (and will make this change) to also update the claims in the session in the API for generating email verification token in case it's already verified.
v
yeah, i use postman as if it was the standard client. Usecase: User is signed in on "device" A (postman). Requests an verification email. User recieves the email on "device" B (firefox) and opens the link on that "device". The browser says "email verified" and the user goes back to device A.
r
yea, in that case, when device A checks the session for if email is verified, it will return 
false
. Then the client should rediect the user to the email verification screen in which the first step should be to call the API to check if the email is verified or not and this would update the session claim. With the new session claim, the frontend should just redirect the user back to their previous screen.
But yea, we should also update the claim when the genertae email verification token API is called.
v
ok thank you for explaining, that makes sense.
but if a user signs in on a new device, the claims are correct?
r
yes.
v
perfect
r
Are you using our pre built UI?
or custom UI?
v
no custom ui
i am using flutter
r
Ah i see.
v
so i am implementing basically the whole sdk myself 😅
r
yea makes sense.
3 Views
PreviousNext
Powered by