Hey, we recently changed the domain our app is hos...
# support-questions-legacyv
vivalapanda
09/16/2023, 5:45 PMHey, we recently changed the domain our app is hosted on and we've started to a get a bunch of fairly mysterious 403s?
r
rp_st
09/16/2023, 5:50 PMHey.
rp_st
09/16/2023, 5:50 PMWhat’s the response body?
rp_st
09/16/2023, 5:56 PM@vivalapanda ?
v
vivalapanda
09/16/2023, 5:57 PMCan't reproduce it on my machine, I'm in the process of adding logging to the supertokens middleware to catch it right now
r
rp_st
09/16/2023, 5:57 PMOkay
v
vivalapanda
09/16/2023, 5:57 PMI can DM you the tokens though
r
rp_st
09/16/2023, 5:57 PMSure.
rp_st
09/16/2023, 5:59 PMseems like that user's email is not verified
rp_st
09/16/2023, 5:59 PMwhich is why they are getting a 403 - makes sense
rp_st
09/16/2023, 6:00 PMif you are using SessionAuth wrapper on the frontend, it should redirect the user to the email verification page
rp_st
09/16/2023, 6:00 PMif the email verification recipe on the frontend is in required mode
vivalapanda
09/16/2023, 6:01 PMI guess the domain would have invalidated old cookies and forced a re-auth
vivalapanda
09/16/2023, 6:01 PMI'll take another look at our frontend to see what might be missing
r
rp_st
09/16/2023, 6:01 PMwhich domains did you change? frontend of backend? or both?
v
vivalapanda
09/16/2023, 6:01 PMboth
vivalapanda
09/16/2023, 6:02 PMThough old f.e. sessions don't have their APIs redirected
vivalapanda
09/16/2023, 6:02 PMintentionally
r
rp_st
09/16/2023, 6:02 PMdid you change the base domain entierly? Or just a sub domain?
v
vivalapanda
09/16/2023, 6:08 PMbase domain entirely
vivalapanda
09/16/2023, 6:09 PMbeta.elicit.org -> elicit.com
r
rp_st
09/16/2023, 6:09 PMso the older cookies shouldn't matter
v
vivalapanda
09/16/2023, 6:09 PMyeah
r
rp_st
09/16/2023, 6:09 PMso this means, that for some reason, post login, the frontend isn't redirecting to the email verification screen anymore.
rp_st
09/16/2023, 6:09 PMor something else is wrong.. not sure. DOn't have too much info
v
vivalapanda
09/16/2023, 6:10 PMHere's my current thinking:
- change was made a ~bit ago that caused a potential error with how 403s get handled
- not detected because we don't have that many people doing email verification
- the new domain caused everyone to have to re-auth (also just potentially many more people signing up/doing email verification)
- this caused the downstream issue of the 403s that we're seeing in our frontend
vivalapanda
09/16/2023, 6:11 PMI think you can ignore this for now, I'll @ if it does seem to be something on Supertokens end
vivalapanda
09/16/2023, 6:11 PMThanks for the fast response!
r
rp_st
09/16/2023, 6:12 PMuhmm. The thing is, when people reauth, and if you have emailverification as required on the frontend, post login, it should just redirect the user to the email verification screen. So you should not be seeing any 403s at all
rp_st
09/16/2023, 6:13 PMi just signed up, and i saw the email verification screen
rp_st
09/16/2023, 6:17 PMright
rp_st
09/16/2023, 6:17 PMso i can reproduce it
rp_st
09/16/2023, 6:17 PMpost sign up, i get an email verification email.
rp_st
09/16/2023, 6:18 PMBut if i ignore it, and manua.ly go to your domain again, then i start seeing 403
rp_st
09/16/2023, 6:22 PMSo the issue is on your frontend code somewhere. Make sure that the mode for email verification on the frontend is set to REQUIRED. Also, make sure to use SessionAuth for protected pages - that should redirect to the email verification screen on its own.
If you are not using SessionAuth, and checking for session manually via doesSessionExist, or via the sessionContext, then check for the email verification claim yourself and redirect to the email verification page if the claim value is false: https://supertokens.com/docs/thirdpartyemailpassword/common-customizations/email-verification/protecting-routes.
2 Views