Google Login does not redirect the user

Ask us anything
1

Hello, so basically, after logging in with third party Supabase providers, I’m guessing that the isAuthorized state does not come in fast enough to redirect the user to the another page. Is there any way, without using JavaScript to detect the change in a variable, or maybe await the variable?

1 Like
2

If I was you guys I’d definitely consider adding some events that come with the JS API Supabase Javascript Client - Listen to auth events to the actions of signup, so we can do something like, await it, or listen to the user change, because as of now, it is just random wheel of luck, whether the user changes soon enough to redirect him :smiley:

3

Are you redirecting to a page that requires authentication?

4

I’m redirecting to a page where I have a redirect set that if the user is not authorized, then it puts him back on /login.

5

The issue is with how the auth process works. When your user lands on that page, they are not yet considered authenticated on your app. They return with a code that must be exchanged for the auth credentials and once the code exchange is complete and the app receives a response with the user object, then you are authenticated.

You could redirect based on the absence of the parameter code in your current url. That would be the more appropriate thing here I’d think.

6

Could you explain more the code part please?

7

Sure, let’s break this down in a simple way:

Imagine you have a locker in school that has all your books and assignments. The locker is locked and only you have the key. Your best friend asks to borrow your math textbook because they forgot theirs at home. Instead of giving them the key to your locker (which would also give them access to all your other stuff, like your history notes, science lab reports, etc.), you want a safer way to let them borrow your book.

This is where OAuth (Open Authorization) comes in - it’s like a special system in the school that lets your friend access just the math textbook, and not everything in your locker. Here’s how it works, step by step:

  1. Authorization Request: Your friend goes to the school office (which is like the server of the app you’re using), and says “Hey, I have permission from my friend to get their math textbook.”
  2. Redirect: The office doesn’t just trust your friend’s word, so they give your friend a slip and ask them to get your signature on it, to confirm you really want to share your math textbook. This is like the app redirecting you to the sign-in page of the service you want to use.
  3. Authorization Grant: Your friend finds you, you sign the slip (like you signing in on the page), and then they take this signed slip back to the office. The signature on the slip is like the code that’s in the URL I mentioned. Although it’s hard to see because the weweb plugin sanitizes the URL on redirect, when you come back to your app from the google signin page the URL looks more like this https://www.yourapp.com/redirect_page?code=23lij3jkbn23b4
  4. Access Token Request: The office sees your signature, and believes that your friend really has your permission. They give your friend a locker pass that can only open the part of your locker with the math textbook (but not the rest of your locker). This is like the app exchanging the code in the URL for an access token. The weweb plugin grabs the code from the URL, removes that portion of the URL, then calls out to google which returns an access token that contains information relevant to the user.
  5. Access Token Response: Your friend receives the locker pass (the access token).
  6. Protected Resource Access: Now your friend can use this locker pass to access your math textbook. They go to your locker, use the pass, and voila - they can borrow your math textbook without having access to anything else in your locker. In terms of OAuth, this is like the app using the token to access data from the service. Only after the access token is obtained can the user be considered authenticated.

And that’s the OAuth dance! It’s all about making sure that even when you let other apps borrow something from your locker (or access your data), you still have control over exactly what they can get, and they can’t get anything else.

So what’s likely happening in your app is that the weweb app recognizes you are not authenticated just before it is able to call out to google and get the auth token. it likely checks that value before it does anything on that page. You should be redirecting to a redirect_page that is not protected/only for authenticated users because when they hit that page, they are not at first logged in from the apps perspective.

1 Like