How To Manage User Roles In Node.js

Key Takeaways

Imagine your favorite website. Let's just say for example Reddit, and now imagine that every user on the site has the ability to delete or edit the comments of every other user. It would not take even just a couple hours for the entire site to go into complete chaos, and the only thing preventing that chaos is a strict strong system of rules and permissions for users. So in this video, I'm going to show you how to set up a really flexible and really powerful rule and permission system for users inside of Node.js. Let's get started now. Now if you create a complex permission system, you're going to need somewhere to host this, which is perfect because atlantic.net, today's video sponsor, is giving you an entire free year-long trial of their service, and these are powerful servers. These servers are actually more powerful than you're going to get in the free trial of most other providers, and you're getting them for an entire year instead of 30 days or maybe even 60 days. That is 365 days. So make sure you check out atlantic.net, link down in the description below, and use the code Kyle to get an additional $50 of credit, which you can use towards anything else on the hosting plan. Welcome back to Web Dev Simplified. My name's Kyle, and my job is to simplify the web for you so you can start building your dream project sooner. So if that sounds interesting, make sure you subscribe to the channel for more videos just like this. Now to get started, I have a very basic boilerplate code set up, and if you want you can download this code from the GitHub link in the description below, but I'm going to go through exactly what I have here just so you know exactly where we are. So the first file is this data.js file, and this is a really basic file. This has all of the different permission roles in our system. For now we just have admin and basic because I just want to show you how this works without dealing with a hundred different permission roles. Also, we have our users, which which going to be taking the place of a user database. You can imagine that this is just a table inside of a MongoDB database that has these three different users. Same thing for projects. We have three different projects, and each user has their own project, and I've just given the project the name of the user as well, so we can easily see which project is whose. And then we also have different roles. The Kyle user has a role admin, and these other two users have the basic role. The next thing that we have is going to be our server.js. This is our main server. In here, we're just starting up an Express server. We're telling it to use JSON, so that way we actually can pull in data from a post request. This is essentially an API. We're also pulling in our project router and making sure that all of our project routes are set up that way. And then we just have a few really basic routes here. We have a get route for the home page, a dashboard page where the logged-in users can see this, and an admin page for admins only. And then finally, we have this middleware, which is just setting our user. So, inside of our body, we're going to be passing up a user ID, and we're actually setting the user based on that user ID from the data inside that data.js file. And then we're just listening on port 3000. So, really basic server. We just have these three routes, as well as all of our project routes. And inside of our project, it's very straightforward. We have a get route to get all of the projects, and then a route to get just a single project. And then this simple route to set the project for this get route here. Really pretty basic boilerplate code. And I also have this file here called test.rest. And if you're using an extension called rest client inside of VS Code, you can actually make API requests directly in VS Code, or you can use something like Postman if you want to make the request that way. So, this test.rest file allows me to, for example, make a request to localhost:3000. If I click send request, you see we get the response of home page, which is the exact same response we have inside of our server.js. As you can see, res.send home page. And the reason this is working is cuz I've run npm run dev start, which just starts up our server. Inside of here, if we see, we have nodemon server.js when I run dev start. So, it just starts up our server and it'll restart it every time we make a change. And that's pretty much the basic code we have. We essentially have a system with a bunch of different routes, but none of these routes are actually protected. For example, this home page, anyone can go to, which is okay. But this admin page, for example, if I send a request, I'm not logged in, no authentication, and I still have access to the admin page. So, we need to make sure that we lock down these different pages based on role, as well as based on what projects the user has access to, and whether or not the user is logged in. So, to get started, I want to go with the most basic form of authentication, which is whether or not the user is logged in. That's going to be our very first set of requirement, because we have this dashboard page, which should be visible to every user as long as they're logged in. But right now, we aren't logged in as any user, so this dashboard page essentially tell us we need to sign in. So, let's go into our server.js and see exactly what we need to do. We can open this up here, and we can see that we have this dashboard page, and we want to write some form of middleware, which is going to take in the user, which we're setting here. So, our user is already set. It's request.user, and we just want to check if that user exist, then continue, otherwise, make sure that they are logged in and send them an error message. And instead of writing this code inside of our server.js file, I want to create a brand new file for this, and we're just going to call this simple file here basicauth.js. This is going to be for a really basic authentication, and we're going to create a function in here, which is going to be called off user. And this is just going to be a middleware, so it's going to take in a request, response, and next, and this is going to check if the user exist, if they're logged in, if so, continue, otherwise, throw some form of error. So, if you remember, I said we set our user on request.user, so we can just say if the request.user is null, then that means we don't have a user. So, what we want to do is take our response and set the status to be 403. That essentially means that you do not have access to this. You're not actually logged in. So, that you need to log in. And then we can return our res. send and it just says, "You need to sign in." Just like that. And we can export this by saying module.exports and we can export that off user. So, now we have this function being exported from this file. And inside of our server here, we can import that off user function, which is coming from Whoops. Require of that {dot} {slash} basic off. Make sure I save both these files. And now what we can do is just simply for our dashboard, we can just say off user. And now if I try to send a request, you're going to see it says, "You need to sign in." And in order to have a user be sent in, we just need to send in some JSON. So, I'm going to tell the server that our application is sending JSON. And then inside of here, I'm going to just send the user ID. And we have a user ID of one. If you remember correctly, we have one, two, and three. So, if I send a user ID of one and send the request, you'll notice it's not actually giving us back a response. And that's because in our basic off, I never actually called next. So, we just need to call next here, which is going to tell our server to continue to the next piece of middleware, which in our case is inside of our server right here to send this dashboard page. And now when I click send request, you can see I get back dashboard page. And if I don't have a user and I click send, you see it tells me I need to sign in. So, we have the most basic form of authentication done, where we say only logged in users can access this page. But if we for example want to do our home page, everyone can still access that whether they're logged in or if we just go back here a little ways, whether they are not logged in. So, here we have a logged-in user and they can access this home page. And if we remove that, they can still access the home page, no problem at all. Now, the next form of authentication I want to handle is going to be for our admin page, because we only want admins to access this. Right now, even non-logged-in users can access the admin page. And users, such as user two, which is not an admin, can also access this page. So, we first need to check if they are a user, and then we need to check that they are an admin to authenticate this route. So, I first want to start by just doing the user authentication, because we already have that written. So, instead of our server, we can just say we want to authenticate that we have a user, and now this route is only available to logged-in users. But, if we want to authenticate this to a specific role, we need to write some code in our basic off to do that. So, we're going to create a function which is called off role, and this is going to take in the role that we want to authenticate. So, inside of here, we need to return a middleware, which is going to be request, response, and next. So, we can say return a function which takes request, response, and next. And then inside of this function, we want to check to see if the role is the correct role. So, we can say if request.user.role, which if we look in our data, we have this role attribute for every user, which is going to be equal to one of these different types of roles from inside of here. So, we want to check if the role is equal to the role that we pass into our off role, then everything is fine. But, if it's not equal to that, we need to do some code inside of here. So, we're going to send a status. This time it's going to be 401. That essentially means you do not have access, you are forbidden, you don't have the correct permission. And then we can just send down to the user the simple text that just says not allowed. Otherwise, if this check is not the case, we can just pass in next here, saying that everything succeeded as we expected. And of course, we can just export that by saying off role down here. Now inside of our server, we can bring that off role in just like that. And inside of our admin, we can say we want to authenticate the user, and then we want to authenticate the role. And in our case, we'll bring the role types in, so we can say role here. This is going to be all of the roles from data right here, this admin or basic. And we want to check for role.admin. And let me just close this so we can see this full screen. And put a comma here. So first, we're authenticating our user. Then we're authenticating the user has a role of admin. And if both of those are the true, then we run the code inside of here. So let's test this out. Over here, we're accessing the admin page with the user no user at all. So we click send, and it says you need to sign in. Okay. Now we're accessing with a basic user, a non-admin user. We click send, and it says not allowed. But as soon as we try to access this with an admin user, which user one here is our admin user, and I click send, you're going to see that it properly returns admin page. So now only admins are allowed to access this route. And the great thing about this off role request that we just created here is we can easily change this to be for basic users. For example, if we wanted this to be basic users only, we could do this, and now only basic users can access it. But of course, for this, we want only admin users to access it. So that's just a really basic way to set up a role authentication for your different routes. And this right here is going to cover most of your authentication needs, but when it comes to specific routes, such as our project route, we need to be a little bit more specific. Because if you remember correctly, in our data, each user has certain projects that they're linked to. So for example, Sally only has Sally's project that she can access. Joe can only access Joe's project. But Kyle, since he's an admin, he can access everybody's projects, even his own. So that's some special code that we need to write in to our projects controller here to make sure that we set up all of that proper authentication. This is where having a really rigorous system around your authentication and permissions is really going to help, and I'm going to show you exactly how to do that. So, let's just close out of this so we have full screen to work with. And what I want to do is create a new folder, which is just going to be called permissions. And inside of here, I want to create a permission for our specific route, in our case, our projects. So, let's just create a new file. We're going to call it project.js. And inside of here, we're going to create all of the different authentications for what we can do with a project. So, if we go over to our route, you can see this route is trying to view a single project. So, I want to create a function in here that says can view project, and this is going to take in a user as well as a project that the user is trying to view. And then I want to return true or false for if the user has access to this project. So, what we can do is just return here user.role equals the admin role. We want to check if this user is an admin because if that's true, they can access every project. So, let's import that admin role real quick. We can say const role is going to be equal to require. We want to just do {dot} {slash} or {dot} {dot} {slash}, and we have data right here. That's going to give us our roles. So, we can say role.admin just like that. And then we want to say or if the user is actually part of that project, for example, in our data, they have that user ID set on the project, then they also have access. So, what we can do is we can say project.user.id is equal to our user.id. So, either the user is an admin or they created that project themselves, then this will return true. Now, let's just make sure that we export that. So, we can just come in here and say can view project just like that. And now inside of our actual controller, we need to set up authentication around that. So, the first thing that I want to do is authenticate that the user actually exist. We never want anyone to access this page unless they're signed in. So, we want to use that off user function. So, we need to bring that in again by just saying const off user and we're just going to set that equal to our require here, which is going to come from dot dot {slash} basic off. And then we also want to bring in our authentication for our different permission here for can view project. So, we can say const can view project is going to be equal to require for oops dot dot {slash} going to the permissions folder and then go into this project section. So, this is going to get that function that we just created. And now we want to create a new authentication, which is going to be for getting a project. So, we'll say off get project just like that and we'll create that function down here. So, we can say function off get project and this is going to be a middleware, so it's going to have request, response, and a next. And now inside of this off get project, we essentially want to use this function we just created and if this is true, allow them access, otherwise do not allow them access and return that forbidden status. So, let's jump over here and we can say if request oops, I'm sorry can view project So, if they cannot view the project and remember we need to pass in our user as well as our project. So, we have request.user and request.project. This set project function is setting our request.project for us right here. So, if we have a project, it'll be right here and if not, we're going to get a 404 error anyway. And to set this, we just pass the project ID inside the parameters here. So, if we cannot view the project, then what we want to do is take the status and we want to send 403 or I'm sorry, 401 and then we want to here return res dot send not allowed just like that. Otherwise, we just call next. Now, we can finally test this to see if our authentication is working for our project. So, let's go to {slash} projects. And we're going to pass in an ID. For example, we'll do project number two. So, only user two will have access to project two. As we can see here, user two is linked to project number two. So, if we come in here and try to send in user three, and if we check, user three is just a basic user. So, they don't have access to any of the projects except for their own. We click send. You see we immediately get not allowed. The user does not have access to this project. If we pass in user two, who is the person that created this project, and send, we get the project back. And if we pass in user Whoops, I'm sorry. User number one. This is the admin user here. This person should have access to all of the projects. So, when we click send request here, you should see that we're getting this request with the project being returned for our user one, as well as for our user two. So, this is great that we're able to narrow down exactly which users have access to individual routes based on other conditions other than just their role. But, we also still have that role-based authentication as well. Now, the next thing that I want to work on is going to be our projects route here. Because this is going to return all of the projects. As you can see, we have a list of all the projects. But, user two doesn't have access to project one or project three. So, we don't want to show project one and three for user two. The admin is going to have access to all of the projects. So, they should get the full list. But, the basic users should only get a list of their own individual projects returned. So, we need to create yet another function inside of our permissions here to handle which actual projects the user has access to view. So, let's create a simple function called scoped projects. And this is just going to take in a user, as well as a list of all of the projects that we want to to that individual user. So, the first thing that I want to check here is if the user.role is equal to that role.admin, then obviously they have access to all of the projects, so we're just going to return the list of projects as it gets passed in. Otherwise, if they're not an admin, we need to limit this role. So, we can just say return here for our projects, and we want to actually filter these projects to only the projects the user has access to. So, we're just going to say project.user ID is equal to user.ID. So, we're only returning projects that have the same user ID as the user that is being scoped to, unless that user is an admin, in which case we return all of the projects. So, we can come down here and say scoped projects, so that we pass that out. And now inside of our project controller, let's just come in here and say scoped projects, and instead of just returning all of the projects right here, what we want to do is say scoped projects for our request.user. Oops. Make sure I put this in parentheses properly, and then pass in the projects here. So, essentially we're passing in a list of all of the projects, as well as the particular user, and scoping that list of projects down to that individual user. So, if I save this and now test this where I pass in user two, send a request, you can see only the projects of user two are being returned. If we go to user three, we're getting only user's three projects. But, if we pass in our admin user and send the request, you see we get all of the projects being returned. So, this system is now handling list, as well as permissions for individual routes. Also, you're going to notice something interesting if we delete this and click send, we're probably going to get an error. As you can see, we got an error here, and that is because we aren't actually authenticating this get route. We're letting everyone access it. We need to make sure that we use off user to only let users access this route. Now, if we send this request, we're going to just get an error saying that you need to sign in. Now, to show you how easy this system is to extend, I want to create yet another route inside of our projects here for let's say deleting a user. So, we or deleting a project. We can say router. delete and we want to delete a individual project. So, we're just going to say project ID. We want to call that set project middleware to actually set our project. We want to make sure that only users can access this. So, we're going to off user here. And then we want to just do another off, but this one's going to be off delete project. And then of course, we have our request and response which are being returned out. And inside of here, I'm just going to send something that says deleted project. Since we aren't actually using a database, I'm not actually going to delete anything. We'll just send out a message. So, let's create that simple off for deleting. So, we'll say off delete project. And all we want to do is change this from can view to can delete project. And then essentially, if they cannot delete it, it's going to send not allowed. Otherwise, it'll continue on to the next. And we want to bring that can delete project function in. So, we'll just import that here, which means we need to create this function inside of here. So, we can come in create the function can delete project, which takes a user and a project. And this is actually going to be the exact same authentication here. We're going to say admins can delete anything. Actually, let's change that. We'll say you can only delete projects you create. Admins don't have the ability to delete your projects. So, you can only delete a project that you create. So, essentially, your ID has to be the same as the project user ID. And if that's the case, then you can delete the project. So, now let's try to test that out. We can just say delete here. And we're going to try doing this for project two. We'll send the request, and we're going to get you need to sign in. So, we can come in here. And we can sign in with our user ID. And we'll say that we want to try this with user three. They don't have access to project two. So, we get not allowed. We send in user two, and we click send. You see that it deleted the project because they have access. And if we send in our admin user, if you remember correctly, we said the admin user cannot delete projects. So, if we click send request, you see again we get not allowed because the admin user can only delete their own project. So, if we try it on project one, you can see they can delete that because that's their own project. And as you can see, the system is really easy to extend. If we wanted to create a new route, for example, editing, we could just create the new route, create a new authentication, and create a new permission, and that's all we need to do. Same thing if we want to create an entirely new controller for users, for example, we can create a new permission for our users and allow different permissions for users to do different things on user objects. And the best part about this system is that these functions are not coupled to your actual routes inside of here, which means that if we wanted to show or hide a link in our view based on if a user can view a project or not or whether or not they can delete it or not. Let's say we have a delete button in our view, and we only want to show that delete button to people that can delete the project. Well, we can actually just use this function, can delete project, and we can show or hide that delete button based on the user being able to delete it because this doesn't have anything to do with our actual controller middleware here. It's completely separate, which is really important about this permission system and what makes it so flexible and so useful in so many different scenarios. And that's all it takes to create this really flexible user permission system. If you enjoyed this video, check out my other authentication-based videos linked over here, and subscribe to the channel for more videos just like this one. Thank you very much for watching, and have a good day.