Okay, so in the previous episode, we reviewed the basics of using Laravel’s Gate facade in your applications. But you might find in some situations, well, this can get kind of muddy. You don't want to store all of the different verifications directly within a method. Well, one option, of course, is much like your routes file, you can reference a class path here and the method you wish to call. So yeah, that's one option. Or if you'd prefer, you can actually create a Policy class. And you'll see we reference these right up here. And then when we boot our AuthServiceProvider, well, we can see that we register each one.

And you'll see we reference these right up here. And then when we boot our AuthServiceProvider, well, we can see that we register each one by calling a policy method on the Gate class. Okay, so let's figure out what that might look like. Now, if I switch to the terminal and run php artisan, you'll see that in the latest release of Laravel 5.1, we have this new make:policy command. And real quick on that note, the version I'm currently using is 5.1.16. Okay, so let's try this out. make:policy. And this will be a policy specifically for, in our case, we're dealing with that Idea.

Make policy. And this will be a policy specifically for, in our case, we're dealing with that idea of posts. So we will have a PostPolicy. Okay, so now you'll see that show up within your app/Policies directory like so. You can inject anything through the constructor. Just like your controllers, you have automatic resolution. So that's no problem at all. Next, well, let's go back to the ServiceProvider. And if you remember, in the previous video, we defined an ability like updatePost.

Next, well, let's go back to the ServiceProvider. And if you remember, in the previous video, we defined an ability like updatePost. Okay, well, now we're going to do that within a PostPolicy class. And we'll call this update. So the policy to update a post will accept a User as well as a Post. And let me go ahead and use those like so. Now we can do the exact same thing as we did before. And now remember, in this case, it's a very simple policy, so to speak. But in real life, you can have more complex things that you need to check for. So just keep that in mind.

But in real life, you can have more complex things that you need to check for. So just keep that in mind. So once again, we can do $userId equals $post->userId. Or we can use that owns method that we created in the previous video. Okay, so now we have a dedicated place for policies related to our Posts. It's very easy to test. This is all great. Now just creating the policy, let me hide the sidebar, isn't enough. We have to register it. We have to tell Laravel about this policy.

We have to register it. We have to tell Laravel about this policy. So we do that through this lookup right here. If Laravel will trigger a policy for you, it needs to know what the connection is. So for example, a Post is connected to a PostPolicy. And remember, if you're in Laravel 5.1, you could always do this number right here. So let's go ahead and do that. And yeah, especially if you're using an IDE, this is a good way to go. Anyways, now that we've defined this lookup, and now just to drill this in, when we register policies, we just filter through all of these.

Anyways, now that we've defined this lookup, and now just to drill this in, when we register policies, we just filter through all of these. And for each one, we basically update an array with the lookup. Okay, in the next video, we'll actually decode how everything works behind the scenes. But for now, that's all you need to know. So that's it. If we switch back to our PostController, we can continue exactly the way we did before. So let's say right here, once again, show that's just a shortcut so we can test this code out. In real life, you might have it on an update method or a destroy method or something like

code out. In real life, you might have it on an update method or a destroy method or something like that. Okay, so we'll say if Gate denies the ability to update a Post, well, in that case, we will abort with a 403 Unauthorized and say nope. Okay, so let's track down the post, of course, findOrFail by ID. We perform our authorization. And then finally, if the person is authorized, we show the post. All right, let's switch to Chrome and try this out. And sure enough, we get nope, we don't have authorization.

All right, let's switch to Chrome and try this out. And sure enough, we get nope, we don't have authorization. And in this case, we're not even signed in. So that works great. But let's go ahead and simulate a user signed in. And we will sign in the User with an ID of 2 who did not create this Post. Well, they shouldn't be able to see this either. So we run it and nope, they don't get to see it either. Finally, we'll change this to 1, the User who actually created this Post, and they alone should be able to view this.

Finally, we'll change this to one, the User who actually created this Post, and they alone should be able to view this. And of course they do. Now real quick, if we go to our view, don't forget about that can directive that we have here. We've changed this to update. So I will modify this. And if we come back, there we go. But now remember, in this case, it's a little redundant because we're saying just for the demo, you can only see this view if you created the post.

But now remember, in this case, it's a little redundant because we're saying just for the demo, you can only see this view if you created the Post. So if that were the case, you wouldn't even need this. But in real life, like I said, anyone should be able to view a Post. So we could remove that entirely and then perform any necessary checks within the view if that's appropriate. So they can see it there. But if you didn't create the Post, you can't see it. Or remember, you can also add, for example, a roles lookup table. And that way you can assign different roles to the users in your system.

Or remember, you can also add, for example, a roles lookup table. And that way you can assign different roles to the User objects in your system. So Bob is a second level administrator. So he can update posts, he can do this, he can work with billing, and you can define all of those roles in a table. And then you can do a simple lookup for each User to determine if they can proceed. And we will review that in a follow up lesson. But yeah, that's all there is to it when it comes to policy objects. So it's important to remember, you can define any number of methods here. And if you want, if you want to follow this convention, you can have your methods correspond

So it's important to remember, you can define any number of methods here. And if you want, if you want to follow this convention, you can have your methods correspond to the methods on your controller. So for example, if you have different logic for whether a person can store a post or create a post, well, then you can do this. And then from your controller itself, you just reference right here, the name of the method. Because behind the scenes, what you define here, that's just the method that will be called on your policy class. So now if you're starting to wonder like, well, how does everything work behind the