00:00 Let's first go to our login where we're going to be rendering the provider connection form. If you dive into that, it's a pretty simple form, just form here with the status button and shows an icon for the provider that we're connecting to. Not a whole lot of complex stuff going on here.

00:18 Probably the most important part here is this form action, that the action goes to slash auth slash provider name, and we're going to provide GitHub. The action is going to be auth GitHub, which we will be doing some stuff to in a bit. Down here below our login form,

00:35 we're going to render that provider connection form. The type is going to be login, and that's really just for the label that we show. It should say login with GitHub versus sign up with GitHub versus connect with GitHub. That's our type, and then the provider name. Right now, all we support is GitHub,

00:54 but in the future, you definitely support others. If I log out here and then we go to login, then we have this login with GitHub. Now, this is going to post over to the action, which we don't have anything there yet. Let's go to our auth.GitHub.

01:13 That's the action that we're posting to. You can even take a look at the DOM output here. We saw it in the component, but there it is. The action, that's the login button here, the login with GitHub, that action goes to slash auth slash GitHub. So that is this action right here. Okay, great. So we're going to need

01:32 the authenticator that we made in the previous step, and we're going to use that to authenticate with GitHub. So we'll say the strategy we want to use is the one called GitHub. If we dive into where this is defined, we've got GitHub right there. So that is where that name is associated.

01:50 Then we're going to pass it the request so that it can use cookies and all that stuff. So let's get the request from the data function args. Then, yeah, we're throwing a 500. We don't want to do that. We actually want to await this, and then we'll just return that value because it's either going to throw

02:09 a redirect or it's going to return a redirect. Either way, I actually don't care that much. It's going to handle that action for us, depending on the current state of the user session and all of that stuff. Ultimately, that will send us over to GitHub,

02:25 and then GitHub will send us back over here. So let's actually get that far at least. So if I click login with GitHub, then this will send me over to my demo app. So that's awesome. Let's go back and let's finish this up. Because once we confirm with GitHub, it's going to send us over here.

02:43 So let's bring in the authenticator. Let's also bring the request in as data function args. We're going to do something very similar actually here. So we'll say this, except in this case, if there is a problem of some kind or if it's successful,

03:03 we don't want the authenticator to send us over to the homepage or anything, because we're going to be managing the session and setting up the user's login and all of that stuff. So what we're going to say is throw on error and set that to true, and then we'll get our results here. So by saying throw on error,

03:21 that communicates to RemixAuth, that we're going to be managing all this stuff. If there's some error or something, don't you try to send them to the error page or anything. We're going to handle that. Okay. So here's our results. I'll call that data, and then we'll console.log data. All right. So let's test this out. We'll go login with GitHub.

03:39 That'll take us over here. You should note that it will only take you over here one time. After you've actually already authorized, then it will actually take you to GitHub, but GitHub will say, oh, they already authorized it, so I'll just send them back. So you actually will only see this page the one time. If you want to, you can go into

03:58 your GitHub user settings and unauthorize it if you want to go through the whole flow again. Okay. So I'll authorize Kent C. Dodds, and I'm getting redirected, and you have successfully authenticated with GitHub. Not really though, JK. Because we haven't actually implemented all that stuff yet, but we'll get to it. Let's take a look at our logs.

04:17 Here I've got my data. There's my user ID. Here's my e-mail, username, all of that stuff. So the whole flow actually did work. We're getting some warnings from MSW because that's how we have MSW configured to give us warnings if there are requests made without us mocking those out,

04:35 which we'll take care of in the next step. But you'll notice we've got a post to the access token to get an access token, a get on the user to actually get the user's profile information as well as their e-mails, and all of that stuff ultimately to resolve to this profile information,

04:53 which we can then use as part of our onboarding. We'll talk more about what we're going to do with this data there. But this is all the data that we need to get this user onboarded into our app. So just to review what we did in this step is, first, we added a form to

05:10 our login page that says Provider Connection Form. It literally just renders a button, but it is an action that goes to this action in our routes auth GitHub action here. We're going to use the authenticator authenticate with GitHub.

05:27 Because our request hasn't gone through the GitHub flow yet, it's going to say, okay, I need you to go over to GitHub first so that we can get all the data necessary for your authentication flow. So then we look at our callback right here,

05:45 and we can see our data right there. Of course, we're calling authenticator authenticate. We say throw on error to say we're going to manage all of those things. I think one thing that might be useful for you to test out is to console log the request.url because there's

06:03 some pieces on that URL that I think you will find pretty interesting. So if I say login with GitHub, then that's going to send me over to GitHub, but it sends me back so fast that you don't see it. That's what I was talking about where now it's not going to show us that anymore. But because I logged out that URL,

06:21 here it is right here. So we get a code and we also get state. So the code is the access code or access token that allows us to start making requests. So we're going to swap that code for an actual access token, and then start making requests to the GitHub API acting as this user.

06:41 So that is something that this is implementation detail stuff of RemixAuth, but that's what that code is for. The state is another thing that RemixAuth actually generates for us so that RemixAuth can associate the state for a particular user who's going through

06:58 this flow to the access code or this code that they're given. So that's another thing that's implementation detail thing for RemixAuth. RemixAuth actually uses that session storage object that we gave to it to store some of this information,

07:14 and that will become very relevant to us in the next step of this exercise. But once we hit that URL, then RemixAuth takes that code and that state, and it starts making those requests with GitHub's API to get all the data until ultimately we're able to retrieve all of our data.

07:32 That is the OAuth2 flow using GitHub.