تماشای این درس نیاز به اشتراک حرفه‌ای دارد.

Dropping Gates for Roles0:00

Now that we have a role-based system, we need to take a step back and decide how we want to control user access. Because, yes, we can use gates. In fact, in the previous episode, we modified the gates to use our roles. But, you know, by defining a gate, we are essentially defining an action. Can a User access the admin, or can they manage articles? And we already kind of have that with the actual role itself. We have defined roles, and a User's access is dependent upon those roles. So I don't think, really, we need to define gates here. And, in fact, we're going to get rid of those gates. Again, we could if we wanted to take that route, but I don't think we need to. Because when it comes to defining or determining how a User accesses routes,

Planning Role Middleware0:45

Again, we could if we wanted to take that route, but I don't think we need to. Because when it comes to defining or determining how a User accesses routes, we could do something like this with middleware. We could say that we will have, not route, we'll have role, and then we can define or specify the role that has access to those routes. So for our UserController, we can say that people with the admin role will have access. And I think that that makes a lot more sense. We have these roles. We might as well use them for our authorization purposes. So let's create some middleware.

Building Role Middleware1:18

We might as well use them for our authorization purposes. So let's create some middleware. We'll make middleware, and let's call this RoleAccessMiddleware. Let's open up the file, and we need the role here. Because how we are going to use this is with role, which is going to be an alias, and then the actual role that we want to check. So our handle method needs the role there as well. But the first thing we ought to do is check if a User is authenticated. Because if they aren't, well, there's nothing else for us to do because the User isn't in a given role.

Because if they aren't, well, there's nothing else for us to do because the User isn't in a given role. So what we can do is redirect them back to the login, and that's going to be fine. So if a User is authenticated, then we need to check if the User has that given role, or rather if they don't have that given role. Because if they don't, then we are just going to abort 403, and we'll say unauthorized action. Otherwise, then we can be sure that the User is in that role, and we will just return the next piece of middleware in the pipeline. So let's make sure that this is actually saved inside of our routes.

and we will just return the next piece of middleware in the pipeline. So let's make sure that this is actually saved inside of our routes so that now only admins can access the UserController. So we can easily test this by signing in with our admin User, and we aren't going to see the user's link because we broke that in the previous episode, didn't we? So let's open up the navigation view, and well, that's why right there. I didn't change the name of the gate, but we're not going to use the gate here. So we're going to have just a normal if. We will get the User and check if they have the admin role.

So we're going to have just a normal if. We will get the User and check if they have the admin role. It's a little verbose, but this is something that we can tackle later on. For right now, I just want to make this work. So now we have access to the user's link in the navigation. If we go to users, we should be able to navigate to that URL, and we can see that the target class Role does not exist. And yes, we are seeing this because we didn't set up our middleware. So we need to open up the app.php inside of the bootstrap folder because we need to add our middleware, and we are going to do so with an alias.

Registering and Testing Middleware3:31

So we need to open up the app.php inside of the bootstrap folder because we need to add our middleware, and we are going to do so with an alias. So we will call the alias method, and our alias is going to be simply role so that we can then specify the middleware that we created. That is inside of the middleware folder, and it is RoleAccessMiddleware. So with that in place, we can refresh the page, and there we go. We have access to our users. But of course, this just checks for our admin user. Let's sign in with any other user. It doesn't matter, so I'm going to pick author@example.com.

Let's sign in with any other user. It doesn't matter, so I'm going to pick author@example.com. And whenever we sign in, we of course aren't going to see the user's link, but if we try to access the user's URL, we are going to get a 403. And that seems to work well, but that only works for a single role. What if we wanted multiple roles to have access to the users? Well, one thing that we might think we could do is just change this to an array like we normally would so that we could specify the different middleware so that if the role is admin or the role is author, then that should work. But it's not because the first middleware is for the admin role.

so that if the role is admin or the role is author, then that should work. But it's not because the first middleware is for the admin role. When the request comes in and we determine if the user does not have access, then we just automatically abort. So it's never going to work for an author. But two, I don't like this at all because this is very verbose. It means that we have to write a lot of extra middleware or specify a lot of different middleware that I just don't want to do. Instead, I want to do something like this so that we can pass in a set of roles and that will determine if the user can access that particular route.

Supporting Multiple Roles5:13

Instead, I want to do something like this so that we can pass in a set of roles and that will determine if the user can access that particular route. It means that we will need to change our middleware so that instead of a singular role, we could have multiple roles. In which case, we would need to supply that to HasRole, but I don't necessarily want to do that. Instead, I think it would make more sense to have like a method called hasAnyRole. And then we could pass in an array of those roles, and it will return true or false based upon if the user is in those given roles. So let's implement that.

and it will return true or false based upon if the user is in those given roles. So let's implement that. We need to go to the User model, and let's just do this right after HasRole. In fact, I'm just going to copy and paste that. We'll change this to HasAnyRole. We will accept an array of roles, and this is going to change so that we will call the roles method wherein the name is any one of the roles that we have provided. And we just want to make sure that one of those exists. And that should get it to work.

And we just want to make sure that one of those exists. And that should get it to work. Let's make sure I've saved all of the other files. And back in the browser, we can refresh. And voila, we have access to the users route. Let's be sure, though, that we can still access them as an admin, which I'm pretty sure we are going to be able to. And sure enough, there's the link. We can access the users. So we now have the ability to determine

Applying Middleware to Routes6:40

We can access the users. So we now have the ability to determine if a user can access a route or a group of routes using this role middleware. And I think it reads very well. If the user is in one of these roles, then they get access to those routes. So let's do a little bit more modification here. I want to ensure that only users that can do anything with the articles have access to the articles. So we are going to use our new role middleware. Those roles are admin, author, and editor.

So we are going to use our new role middleware. Those roles are admin, author, and editor. And they will have access to the articles resource. But then when it comes to accessing the users, we only want admins to be able to access our users. But this is only part of the problem. Yes, we are determining what users can and can't access parts of the application. But now we also need to essentially take this same concept and apply it inside of our views. Like, for example, inside of the navigation view

and apply it inside of our views. Like, for example, inside of the navigation view where we determined if we need to show the users link. I mean, yes, we can do that by using our hasRole. And now we have that hasAnyRole method. But I don't necessarily want to do that. That is a lot of code for something that should be relatively simple. So in the next episode, we will address that with a custom directive.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟