Hi! I am trying to develop my custom UI with supertokens, and it seems that everything is working correctly. Except one thing... My signup/signin flow works like this: First a user signs up using email/password or social signinup then the frontend redirects it to a set username route where the user has to set a username and then an email verification link is send. I have overwritten the following functions:

doesSessionExist

and

getRedirectionPath

. It works like a charm with email and password, and also with the Facebook Provider. However, it doesn't seem to work with the Google Provider. Every time I try to sign in or up with the Google provider I get redirected to my dashboard not the set-username route. If I refresh the page supertokens instantly remembers that there shouldnt be a session and redirects me to the set-username route (The only difference I see is that you do not need to verify the Google email address, while you need to verify the Facebook email, which should be handled by a logic in the doesSessionExist where we first check the atp and then check the email). Seems like a strange thing to me...

Hey @flixoflax can you show me the modifications to getSession function?

Sure! this is my supertokensConfig

So whats the value of

accessTokenPayload.isUsernameSet

post facebook sign in vs post google sign in?

Should be the same ""

yup. And is it?

since the backend creates the atp every time a session is created

right. So then doesSessionExist should return false then. So post login, SuperTokens calls the

getRedirectionURL

function. Can you add console logs to that and see where the execution flows in case of google sign in vs facebook sign in? I think the issue lies in that function's customisation.

just tested.

Hmm. So what behaviour are you seeing with google? That it redirects you back to

/

?

yes

Have you wrapped your app with the SuperTokensWrapper component?

yes

alright. @porcellus can help out with this. Just gonna ping him

okay top thank you.

hmm, as far as I can see it should be called regardless of email verification. Can you test the call order of your overrides during a google sign up? I mean

doesSessionExist

,

isEmailVerified

,

getRedirectionURL

and

onHandleEvent

(with

context.action

in the last two)

@porcellus Hey, same procedure for google and facebook except google is not running the getRedirectionUrl at the end

and

getRedirectionURL

gets the

VERIFY_EMAIL

action for facebook, right?

Not sure what you mean by that. You can see the overwritten function here

well,

getRedirectionURL

is called with a context (the only param), that has an action prop.

Yes sure, let me check with which context it gets called

hmm, so my current guess is that the

getRedirectionURL

is not applied to the

thirdparty

recipe properly (as a sub-recipe of

thirdpartyemailpassword

. I see no reason it should be like that, I'll investigate and get back to you in a bit.

Can you open an issue about this on our github @flixoflax - we will work on a bug fix ASAP.

I'm having a bit of trouble reproducing this. Could I see more of the code (maybe get access to the project)?

Sure! Will do!

Hey! You can add me to the project and I’ll send it to porcellus. My username is rishabhpoddar

I'm porcellus on GH as well, but adding @rp_st works too

@rp_st @porcellus Hi, I opened the issue, and invited you to both of the projects... one with the -auth and one with the -web suffix

thank you.

@flixoflax Hi, so I've checked out why/how things work in your app: - You never get a success redirection; that only happens if you use our pre-built UI components. - Your

doesSessionExist

override is only called during full-page reloads. If we create/refresh a session, we set the value to true in the context while handling the event without calling

doesSessionExist

. This explains why it "remembers" that it's not supposed to have a session after a refresh. -

getRedirectionPath

is only called in your app by the

ThirdPartyEmailPasswordAuth

, if it detects that the user has no session or is missing email verification. Since you always have a session after sign-in, it explains the issue with third-party providers that mark the email address as verified. My recommendation: Replace

ThirdPartyEmailPasswordAuth

with your own component that uses

useSessionContext

and does the email verification, user name, and session checking and handles redirects. This way, you can remove the

getRedirectionURL

, and

doesSessionExist

overrides, which should be a bit cleaner in general.