Manage Third-Party Authorization Errors in Supabase
In this lesson, we'll go through the errors for authorization with supabase using a third party which in this case is GitHub. Also, we will set up the process of authorization as desire, either with a confirmation email or not, when logging in.
Lecturer: [0:00] It wasn't quite clear to me at the beginning what this error was. This is maybe one unfortunate thing about using third-party OAuth providers in a system like this.
[0:08] An error isn't really persisted here. You can see, it doesn't show up here in the URL or anything like that, so it can be a little unclear what exactly is going wrong. What I realize here is that what it's actually doing is trying to send a Confirm Your Sign-Up Email to my email address, for whatever the third-party OAuth provider that I did was.
[0:29] If I come here, I can see it sent an email to my email address associated with my GitHub account. If I confirm my email, you can see that it sends me to localhost:3000, a different project running on my computer with an access token. It is trying to authorize once I've confirmed my email.
[0:48] What's happening here is that you may find when someone by default is trying to sign up with your application, there's an email authentication workflow that is stopping them from doing really simple, "Click this button and immediately be logged in."
[1:02] There's a couple of things we're going to change here. Though, you don't have to follow all this exactly if, for instance, you do want email confirmation for third-party OAuth users.
[1:12] First, we're going to come here into the settings and into the auth settings. I'm going to disable email confirmations. You won't have to go and click that extra link if you try and sign in using GitHub or something like that. I'm also going to update my site URL. Right now, I'm using localhost:3001. That will mean that when I log in, it'll redirect to the correct location.
[1:37] Now, if I save both of those, and I come back to my application, and click log in with GitHub, I now get an error here saying, "Server error and error description, database error saving new user."
[1:49] This issue can happen if Supabase isn't able to fully create your user the first time around. For instance, the email confirmation didn't work. It didn't do the full workflow of going from Supabase to GitHub and back to Supabase.
[2:03] The easiest way I found to get this to work is to delete your user. Delete this one in the auth users' table. This won't be something that you'll probably run into in production, as long as you have your stuff set up correctly here, like your site URL.
[2:18] If this is correctly set up, and email confirmations are disabled, you can go through the entire flow correctly. You won't run into issues. With no users here defined, let's come back into our application, and we'll refresh.
[2:30] If we click log in with GitHub here, you can see that it will update the URL. There was a little blip here with the access token, and then it says logged in. If we come back, and we refresh our auth users table, you can see that there is a new user here.
[2:44] Email's krishnakrishnaprema.com. Provider is GitHub. This is a new user. If we come to the table editor here, and we look at our users table that we created earlier, you can see that there are two users. Signal nerve and my first user.
[3:00] These are the example users that we created when we were walking through this workflow earlier. Then we have a new user with a UUID of fc8bo0, etc. Then a username which is null.
[3:14] If you don't know what this is, this is our new user created based on the trigger that we wrote earlier. You might remember that we said when a new user is created on the auth.users table, we want to create a new user in our public users table, right?
[3:29] Public.user which corresponds to that, which we can use publicly to store more user interface friendly data. That is what this user here is.
[3:40] In fact, now that we're at the point where we're creating our own users using the Supabase JavaScript client, I think it's probably about time to delete this test user data too. Let's come to the messages table.
[3:50] You remember we created a message here, which we will just delete. Then we'll also come in here to the users table and delete these two fields so that all we have left is data that's actually being created by our application.