Loading
Current section: Protecting Routes 6 exercises
solution

User Authentication and Authorization

Loading solution

Transcript

00:00 So let's get started by exporting a function called requireUserId and Copilot can actually do most of this stuff for us because it's pretty simple. It's just the opposite of this require anonymous that we did already. So we get the user ID with that util. If there's not one,

00:15 then we're going to throw a redirect to the login and then we'll return the user ID as what we give back. So if we apply this to all these pages, then we need to get the user ID

00:29 with the requireUserId util. So requireUserId with the request and it is async, so let's add a wait right there. And yeah, that's all there is to it. So now the profile page is protected and we get the information that we need to retrieve the user. So that works out nicely.

00:48 And then with the profile photo page, here we have this. We're going to require the user ID. We're going to need to get the request from data function args. And there we go. Now we get the user that we need. We're also going to need to apply this to the action as well to protect the

01:07 action side because just because a user can't appear on the page, they can't load the data from the page, doesn't mean that they can't submit data to change that data on the page. So we want to make sure that we cover both sides as well. Okay. And then for the password page,

01:26 we'll do the same here, bring in our utility, and that's in the action. And this one doesn't have a loader, so we don't need to worry about that. The user could appear on this page, but because of the nature of nested routing, they won't actually ever make it here because

01:43 the profile parent route will kick them out anyway. So we could add a loader just to do this check, but we don't really need to because that's going to be handled by our parents that will do the check and eject them in that case. However, if we did want to load some data on this page,

02:02 then we still would want to do require user ID because one, you'd want to make sure that nobody could load random data. And then two, because we're probably going to need the user ID anyway. So that's kind of the nice duality here is that you're going to need that loader data anyway,

02:22 so may as well, or you're going to need that user ID anyway. So you may as well boot them out if they're supposed to be logged in, but they're not. Okay, great. And actually, in addition, they wouldn't really be able to get much useful information here anyway, because the only information that we can give them is the information for the user that they're currently

02:41 logged in as. So let's use our util right here in the loader for the profile index page. And then we also have an action on here as well. And with that, the last one is for the download user data page.

02:57 So we have the ability for users to download their data. And with all of that, now we can finally go to our profile. And we can see all the stuff that we have here, this is protected by our changes saved, hooray. And now we're very excited, Cody. And then we can go to our change

03:17 password. And we can make a change to the password. And we're allowed to be there. But if I were to try to go there, and I'm not logged in, like we go here, then we say go there, it's going to send me back to the login. And that is exactly what we want to have happen. Then of course, we

03:34 can download our data. Whoo, go resource routes. Alright, so quick review what we did. The biggest thing was this utility require user ID, where we get the user ID. And if there is not a user ID, then we'll throw a redirect to login. And then we'll return the user ID. And that allows us to

03:53 have some user specific routes.