User authentication and authorization are vital parts of any application, because, of course, that allows us to control what users, first of all, have access to the application, and then also what those users can do. But there can be a lot of confusion between authentication and authorization. I guess because they both begin with auth, but they are two completely different things. So authentication is the application taking the user credentials and verifying that they are correct. And that's it. Of course, the application needs to ensure that a user is authenticated. But that's, you know, that's it. And that's the easiest thing. And, in fact, we get that for free whenever we create a new Laravel project using any of the starter kits. But authorization, well, that's a completely different beast.

And, in fact, we get that for free whenever we create a new Laravel project using any of the starter kits. But authorization, well, that's a completely different beast. That controls what a User can and cannot do. And that is also the most, well, it can be very simple to implement. It can also be very complex. So in this series, we are going to look at different strategies and different features that Laravel provides for user authorization. And we're going to start with the easiest approach. So I have a very simple application. We have some articles. We have some users who can create articles.

We have some articles. We have some Users who can create articles. And I'm going to sign in with my testUser. And any user who signs in is, of course, authenticated, but they can view all of the articles. They can edit any of the articles. They can delete them. They can create them. They can also manage the users. And while we can't change the password of those users, we can change their names, their email addresses, and we can even delete them. And that's definitely not something that we want.

And while we can't change the password of those users, we can change their names, their email addresses, and we can even delete them. And that's definitely not something that we want. We only want certain users to have that power. And so the easiest way that we can approach this is to just add a column to the user table. So let's open up the migration for our user table. And let's see, after password, let's add a new column. This is going to be a Boolean column, and we'll just call it isAdmin. Let's set the default to false. That way, any new user isn't accidentally set as admin. But even though this is a simple change, there are other things we need to touch.

That way, any new User isn't accidentally set as admin. But even though this is a simple change, there are other things we need to touch. Like, for example, we need to open up the User model because we should add the isAdmin column as fillable. And we also need to add it to our casts so that it will be cast as Boolean. But then we also need to visit our UserFactory because we need to include that whenever we create a User. And I'm just going to do this. We'll say that some users will randomly be admins, others will not. And then finally, I need to go to the DatabaseSeeder because for my test user, I want to ensure that it is an admin. So we will set that to true whenever we create that, and that should get us going. So I am going to, first of all, wipe the DB so that we can run the migration and then seed it with the new data.

So we will set that to true whenever we create that, and that should get us going. So I am going to, first of all, wipe the DB so that we can run the migration and then seed it with the new data. So hopefully the migration will go okay. It does. Then we will run DB::seed(). Hopefully that will complete. And so now we can control who is and isn't an admin. But of course, the application needs to be set up to do that. So let's start in the view that shows all of our users. That's inside of views/users/index. And we're going to add another column to this table. And it can be after email address. It really doesn't matter the order of these.

And we're going to add another column to this table. And it can be after email address. It really doesn't matter the order of these. But I think that this will be fine. The heading will be simply admin, and then our value will just be output here. So once again, we can sign in with my test user. And whenever we go to the users, we now see our admin column. And we can see that there are several admins. And I guess that's okay. But the first thing I want to do is hide the users table from any non-admin. So the first thing that I can do is open up the navigation view.

But the first thing I want to do is hide the users table from any non-admin. So the first thing that I can do is open up the navigation view. And for the users link, we can check if the auth user is an admin with just a simple if directive. If auth user is admin, then we want to show this link. Otherwise, it will be hidden. So that way, non-admin users will not even be aware that the user administration is even an option. But, you know, we can't really test with our test user. So let's grab one of these other users. And instead of an incognito or a private session, let's sign in with the user. And sure enough, the users link is not available.

And instead of an incognito or a private session, let's sign in with the User. And sure enough, the users link is not available. However, if someone like ourselves is curious, we can start playing around with the URLs. And if we try to go to /users, well, we can still access that. And so the obvious thing for us to do would be to open up the UserController. And then inside of every one of these action methods, we would check if the User is an admin. Or rather, I guess we would do this. We would check if the User is not an admin. I guess let's do this. Let's use the Auth facade.

I guess let's do this. Let's use the auth facade. And if the User is not an admin, then we will simply return a 401. Our response will be unauthorized 401. And so back at the session with our normal User, if we refresh, we see that it is unauthorized. But then the User that is an admin can still access that. But that's not a very good approach. Because now we have to go into every method on every Controller that needs to be protected for admins and check if a User is admin. That's not realistic. Instead, it would be really nice if we could do something whenever we define the route.

That's not realistic. Instead, it would be really nice if we could do something whenever we define the route. You know, kind of like using the auth middleware. That way, we can protect as many controllers and as many resources that we need all at once right whenever we define those routes. And we will look at how to do that in the next episode.