Current section: OAuth 6 exercises

Simulating GitHub Authentication Flow with Mocks

Loading solution


00:00 The first thing we're going to want to do is go to our ENV here and prefix both of these with mock underscore. Just to communicate these are mocked and our server will behave a little bit differently. Our mocks will behave differently based on the fact that this is prefixed with mock.

00:15 Okay, great. And then we can go to our Auth GitHub route right here. And this is what handles, or this is the action that handles me clicking on this. So right now if we let this go through this is going to send us to GitHub and we don't want to do that for our local mocking.

00:32 And so instead we're going to add an if statement here that says if the GitHub client ID starts with mock underscore then it's going to do this instead. Otherwise we can go ahead and do the regular flow because maybe you're testing the full flow altogether.

00:47 So basically we just need to simulate what this would have done if we weren't in a mock environment. And so it does a couple of things. We've got a step-by-step process here. So first we're going to get our connection session from await connection session storage dot get session

01:05 from the request headers get cookie. And then we're going to create a state. So this state is just going to be some randomly generated string.

01:19 And so we're going to import import create ID from that parallel drive qid2 as qid. And that will create a random ID for us for our state.

01:33 It actually really doesn't matter exactly what that value is but it just needs to be some unique value here. Okay so then we're going to do a little bit of RemixAuth specific stuff here. And so RemixAuth stores that state in a cookie so that it can associate that state.

01:50 When that URL comes back or that code comes back it's going to have that state in the URL. And so that's how it's going to be able to validate that yes this code is for this particular auth flow. So we're going to set that in the session but then we also need to set it in the URL search params that we're sending the user over to.

02:09 So let's also create a const code. And this we're going to say mock code github Cody. And that's going to match the mock code that we're going to create for Cody here in a second when we do the database aspect of all this stuff. And create a connection for Cody right from the get go.

02:28 Alright so with this now we're going to get our search params. And that's going to be or include the code and the state. And then we need to send the user over to where they're supposed to go. So that's send them over to auth github callback. This is what github would do.

02:44 And it will also include a code and the state that we sent over to github through RemixAuth. And so it sends our users back to this route with those search params. But we also need to commit this session change that we just made.

03:01 Let's do our headers and set cookie and await that. There we go. So we're going to commit the session to get that set cookie header. And that is it.

03:14 In quick review all we did was prefix our environment variables with mock underscore. And then we grabbed the connection session storage which is what our RemixAuth authenticator is using.

03:29 We set some state in here so that when it goes to look up that state in the cookie it finds that state properly. We specify our code and then we specify the URL search params for this redirect. And then we commit that cookie so that when RemixAuth goes to look up that state

03:47 and compare the state between the URL and the state that's in the cookie, those two will match and be verified. And then we can proceed as if we had gone through the whole GitHub flow before. And thanks to our GitHub mocks that we have, even though we're giving a completely obviously fake code,

04:06 we're not actually hitting the GitHub API and so we can handle those ourselves.