Not all routes in an API should be publicly available. Scott goes through the post, category, and user modules to identify routes which require authentication. He also explains edge cases where a route should only be available to a single user versus all users.
(upbeat music) - So now if we go back and look at those other methods like, an auth.js, like decodeToken, and varify user, oh, I'm sorry, decodeToken and getFreshUser, we're actually about to use these now. Well, we got to think about, like, it's going to go down to like, what resources do we want to protect? So let's just go and look at them. Let's go look at... Let's go look at categories.
Let's look at the category routes. Are there any routes in here that you think that you should be authenticated to access? - [Male] Post. - Post, right? You should definitely be authenticating to be able to create a category, I agree. Anything else? - [Male] Delete. - Definitely, you should be authenticating a delete for sure - [Male] And probably Put. - Put, updated category, for sure.
Yeah, that's about it. Everybody else should be able to get all the categories or get one category, yeah, I agree. And then what about, let's go to the posts route. And then for this one: same thing or something different? Probably the same, yeah, it's about the same. Everybody should be able to get one and get all, but only authorized people should be able to update, delete, and create.
And then for users, there's some extra stuff going on in here, so, hold, then I add that there? Alright, wait, wait. Yep, I did. Right, and then for users, what about this one? - [Male] Probably the one get all your users. - Probably the one that get all the users.
What about getOne user? Like, what if I want to see, what if I go to the blog, and there was a link there that says look at all of our authors. Isn't that get all users? So there may be a way, maybe you want to get all users but you don't want to show all the information on the user schema, like their passwords, and stuff like that. Here's their password, pass, but it's right there. (laughter) So maybe post, so who should be able to create a user? - [Male] Anyone can create a user, right? - Yeah, anybody can.
On a real blog, no way. You would have to be invited. I'd have to type in your email, and like, you're invited to write on the blog, like Wordpress. But in our scenario, yes, anybody can go to our website and sign up and start publishing. So yeah, anybody should be able to create. Whereas that was different with the post. Only authenticated people should be able to create, so that's why I want to talk about it. What about updated user? Who should be able to do that? - [Male] Only that user. - Only that user, so not only should you be authenticated, but you should can only update yourself.
Alright, so that's different. But what about if I'm, like, an admnin and I want to update your stuff? - [Male] You go into the database. - I'd got to do it from the ground up. - [Male] No, we're not doing none of that ___ stuff. (laughter) - Okay, okay, yeah, we're not there. We don't have a role-based authentication schema anyway so there's no admin, it's just we're both users anyway so I don't have superpowers. What about delete? Yeah, think about that.
It's deep. Have to be authenticated because you probably won't be yourself for now. So I just want you to think about that stuff because now you're going to have to write the middleware in the places that they need to be, so this stuff works, alright. So if you go back to auth.js, we have the two middleware functions that we need are going to be decodeToken and getFreshUser. But I want you to remember something. The first thing, the order is very important here because decodeToken is, it should be like the first line of defense.
It's job is to decode the token and attach req.user or it will attach whatever that object is that it decoded to req.user, which in this case because of sign, it's just an object with IDs on it. So that should be the first thing that we do, and right after that, before we get into the controller, we should get the fresh user, and that's because if you go look at our controllers, let's just take an example of user controller. It's expecting, not getOne because it's going to ID from there, but let's see, where is one at? Not this one, or not this one.
This is a bad example, let's go look at post. Where, okay right here. So this one right here because the post, we'll have to update this, but remember, the post has like an author field. It needs to know what author is creating it, so if we didn't do that on the front end, put the author key there, we'll have to do that here. And we would, that'd be fine because we know who the author is because it's req.user._id cause they're the only ones to create this post, so they create it and it's there.
So params is a way to get the resource, to ID the resource that's coming in. What I'm saying is getFreshUser will just attach the user of the incoming request. It doesn't matter what request we hit. If we use the getFreshUser middleware, it will attach the decoded token, turn it into, it'll search the database for that user, and attach it to req.user, which can be helpful in most controller operations. Maybe you need access to the entire user to do things. It's very helpful. One place that it's very helpful, now that we're using json web tokens, is that, let me ask you this: how would I get myself, if all I had was a json web token on a client, how would I ask the server, hey, give me my own user object? How would I do that? We know how to get one user object, and that's /api /user /id.
I don't have the ID, all I have is the json web token. So how would I do it, yes? - [Male] Well, if you decode the token, it has an ID. - Where would you decode the token, on the client? - [Male] On the server, cause that's where the secret is. - Right, so like, we don't have a request for that. We don't have a controller for that, is what I'm saying. Like, what would you hit, what route would you hit to do that? Cause if we do a Get to the user, it will give me all the users. If I do a Get /id, it will give me the user for the ID, but I don't have the ID, so I can't do one of these.
- [Male] You would have to make a new route. - Have to make a new route, exactly. What would that route do? - [Male] Take the token. - Right, that route would... - [Male] Be like me and then take the token. - Exactly, you make like a /me, which is a common thing you'll see in like tokens. So it would be like api / user/ me . And all that would do is just send req.user back, that's all it would do. Because it would already use this middleware getFreshUser, which it had already found the user before it went to that /me controller, so all me would just be like, oh req.json, req.user, or res.json, req.user.
This course was created by Frontend Masters. It was originally released on 12/30/2015. We're pleased to host this training in our library.
- Executing Node.js
- Using Express
- What is middleware?
- Testing in Node.js
- Using Mongo with Node.js
- Data modeling
- Querying data with Mongoose
- Identifying sensitive routes
- Configuring the deployment