To give you an idea of how I create these videos, I typically batch record during the week and then I batch edit on the weekend, primarily because I want to break between the two. By the time I'm done recording an episode, the last thing I want to do is hear myself talk about what I just recorded. It's just I'm tired of hearing my voice, and so that gives me an opportunity to go back over the things that was covered, the code that I wrote or presented, and just to see how stupid I am sometimes, because, you know, we all do it. We all write code, and we all return to that code at some other point, and we think, what in the world were we thinking?

We all write code, and we all return to that code at some other point, and we think, what in the world were we thinking? And yeah, permissions are one of those things. Let's look at the StoreUserRequest, because this set off red flags, and no, that wasn't the right one. The StoreTicketRequest. The set off red flags, I knew this was not really the best approach, but I wanted to get it done so that we can move on. How many times do we do that, and then we regret it? So okay, as a refresher, this is a request that's being used by the TicketController.

How many times do we do that, and then we regret it? So okay, as a refresher, this is a request that's being used by the TicketController and the AuthorTicketController, and so we needed to get the appropriate authorId attribute so that we could assign the correct rules for that. And in this particular case, the default rule was for, like, a manager or an admin so that they could create a ticket for any User. But then we checked to see, well, if the User can only create their own tickets, well then we need a more restrictive rule. And it works, but it forced us, or forced me, rather, to add this comment to the getAbilities method on the Abilities class, and that was to not assign an asterisk.

And it works, but it forced us, or forced me, rather, to add this comment to the getAbilities method on the Abilities class, and that was to not assign an asterisk. Because if a user has an asterisk as an ability, this if statement is going to be true. Therefore, it's going to limit their ability to create tickets for other users. And that's not the approach. That is the wrong thing to do. I should have designed that a little bit better. And it's really not that hard. All we need to do is follow the concept of least privilege, or the principle of least privilege.

All we need to do is follow the concept of least privilege, or the principle of least privilege. If you're not familiar with this, it's not a programming thing. It's just a security thing. The idea is that regardless of what the user is, you assign the most restrictive permissions for that user, and then if they need more authority, you grant them that authority. So if we were going to follow the principle of least privilege, we would do two things here. The first would be that for every User, it didn't matter if they were a typical User, or a manager, or an admin, they would be assigned the createOwnTicket, updateOwnTicket,

The first would be that for every User, it didn't matter if they were a typical User, or a Manager, or an Admin, they would be assigned the createOwnTicket, updateOwnTicket, and deleteOwnTicket abilities, because those are the least privilege. But then if the User was a Manager, we would also assign these other abilities. And if it was an Admin, it wouldn't matter. We'd give them the * so that they could do all of the things. And we don't necessarily need to do that here. But we do, however, need to apply the principle of least privilege in our rules. So for the sake of creating a new ticket, we need to set as the default validation rules the most restrictive rules.

So for the sake of creating a new ticket, we need to set as the default validation rules the most restrictive rules. That means that by default, the author_id attribute needs to match the signed in user's id, because that is the least privilege for any user. But then if we needed to grant more authority, like for example, for a manager, if they can create a ticket, then we modify the rule so that they can create that ticket. So this means for all users that can only create a ticket for themselves unless if they have the authority to create tickets for anyone. So that would be a manager, or if an admin had an asterisk, then this would grant them the ability to create a ticket for any user.

So that would be a manager, or if an admin had an *, then this would grant them the ability to create a ticket for any user. But now we have two strings that are essentially the same, and that means we need to create a variable to store that. So let's just call this authorRule, and we will start with that so that for the default rule, we will take that authorRule variable and concatenate that with the size to limit the userId. But then if the user can create a ticket for anyone, we set the more authority there. So that would solve our problem, and we're good there. But I think we also did that inside of the updateTicketRequest.

So that would solve our problem, and we're good there. But I think we also did that inside of the UpdateTicketRequest. So in this case, the authorId should be prohibited by default, and then if the User has the authority to update a ticket, then we should grant them the authority to update the authorId. So that would fix that problem. We can now assign an asterisk to a User because that's part of the system. We need to build for the system, so therefore we are good to go there. So crisis averted. But I'm not done talking about permissions because if we take a look at the TicketController, you know, we have this isAble method.

But I'm not done talking about permissions because if we take a look at the TicketController, you know, we have this isAble method. This is a method that we use so that we can check the appropriate policy for an ability and a model. It is modeled after the authenticate method, but I would prefer to do something like this to where we would have an if statement isAble to update the provided ticket. Well, then we would update the ticket, return the TicketResource, otherwise we would return the error stating that user is not authorized to update that resource. That way we can get rid of the other catch for the authentication exception, and this just makes our code a little cleaner.

That way we can get rid of the other catch for the AuthenticationException, and this just makes our code a little cleaner. So we can easily do this. All we need to do is modify our isAble method here so that inside of here we try to authorize the $user. And if that succeeds, we return true. We will catch the AuthenticationException, in which case we will just return false. So that means we can go back to our controllers and we can modify these so that we could have an if statement and then do what we need to do. Otherwise, we return our notAuthorized message.

an if statement and then do what we need to do. Otherwise, we return our not authorized message. Let's scroll on down and let's use an if statement. If isAbleToDelete the ticket, then we will delete it. We will return an OK response. Otherwise we return the unauthorized message saying that they cannot delete that resource. We should probably look at the store method because I'm pretty sure we check that ability. We do here, so all we need is an if statement. Return the new TicketResource if we can, otherwise we return our error. Now we can do that in all of our other controllers.

Return the new Ticket resource if we can, otherwise we return our error. Now we can do that in all of our other controllers. I'm not going to do that on screen because it's quite a bit and you don't need to see me doing that. Or rather, you don't want to see me doing that. Now in the next episode, we will talk about handling errors, which we've kind of done, but we need a more complete and comprehensive approach.