Behavior of redirectUrl and redirectUrlComplete on the signIn.authenticateWithRedirect function

[rodrigotavio91]

The authenticateWithRedirect function has the props redirectUrl and redirectUrlComplete that I'm finding confusing to understand the difference by observing the real behavior. In my app, the redirectUrl goes to the sso-callback, while the redirectUrlComplete goes to the user's home page.

What I'm noticing is that the redirectUrl is only used when the user sign in for the first time (sign up), while the redirectUrlComplete is only used when the user already has an account (sign in). On the latter case, the redirectUrl is ignored. Is that always the expected behavior?

If so, then why on the sso-callback - on the AuthenticateWithRedirect component - I have to specify the afterSignIn and afterSignUp props? It will only using the afterSignUp path.

Maybe that changes depending on the provider? I'm only testing with Google.

Thanks!

[gfarhan18]

@rodrigotavio91 , have you found any solution for this?

[rodrigotavio91]

@gfarhan18 I assumed that was always the behavior. On the authenticateWithRedirect function, the redirectUrl is my app home page, while the redirectUrlComplete is the sso-callback. On the AuthenticateWithRedirect component on the sso-callback page, I have set the redirectUrl to the home page too, instead of setting afterSignIn and afterSignUp to the same URL.

It worked as expected, but I end up switching to Supabase Auth after due to the lack of support for the native Apple sign in.

[praveenaj]

Yes, redirectUrl is used for the first-time sign-up, and redirectUrlComplete is for any sign-in attempts, if the user is already in Clerk.
I was able to get this working by setting the URL with signUpFallbackRedirectUrl prop in <AuthenticateWithRedirectCallback> (https://clerk.com/docs/components/control/authenticate-with-callback)

[jescalan]

https://github.com/orgs/clerk/discussions/3829

[renniehaylock]

Not having this exact same issue, but I was also having issues following who gets redirected where in different scenarios and went down a rabbit hole. The <AuthenticateWithRedirect /> component essentially looks at the state of signUp and signIn attempts, looks at all the defined redirectUrls (afterSignUpUrl, afterSignInUrl, etc) and decides where the user should be taken next; it does the heavy-lifting around taking care of all possible scenarios (including handling Oauth transfer flows). It's been really helpful to look at the code that handles the redirect logic. You can find it here.