All right, so if we can think of the GATE API, sort of like the route closure equivalent for authorization rules, well then policies are sort of like the controller equivalent. They allow us to assign authorization rules specifically for a model. Let me show you, Let's make a new policy and this will be well for what model? Well, for the idea model. So let's call it idea policy. And actually it's a quick little tip.

Well, for the idea model. So let's call it idea policy. And actually it's a quick little tip. If you're ever unsure about how to name a particular class. Well, when you run a make command, Laravel will give you a suggestion. Now, of course you can do whatever you want, but the suggestion is usually the common convention. Alright? So once again, idea policy. Alright, so what is the corresponding model? Once again, it is idea.

Alright, so what is the corresponding model? Once again, it is idea. Alright, so now you can see we have a new policies directory within the app folder. So if I open my sidebar, sure enough, app policies, here's our policy. Alright, so outta the box, it's going to include a bunch of things. And you don't have to keep all of these. Think of each of these methods as, uh,

And you don't have to keep all of these. Think of each of these methods as, uh, representing a potential rule that you might want to implement. For example, for an idea, can the current user view it? Uh, or can they view any of them? Can they view a single one? Can they create a new idea? Can they update an idea? Can they delete it? You get the idea. Can they restore a soft deleted idea? However, I think what you're probably gonna find is in

You get the idea. Can they restore a soft deleted idea? However, I think what you're probably gonna find is in so many cases, you only need one or two methods to declare your authorization rules. So for example, if it helps review these, but then just get rid of whatever is irrelevant and trust me, that's totally fine. So in this case, we're gonna start very simply, let's determine whether or not you can update an idea policy and yeah, make sure this doesn't have to correspond

let's determine whether or not you can update an idea policy and yeah, make sure this doesn't have to correspond to the update method. For eloquent, this just means can we update one? Um, can we work with it, can we tweak it, can we edit? Can we create, can we delete, can we, can we modify it? And yeah, if you want, you can even change this to modify, so you can choose what your conventions are. Okay? Anyways, I'll stick with update. So Laravel is going

Okay? Anyways, I'll stick with update. So Laravel is going to feed us the currently authenticated user. And just like with the GATE API, it's the same thing. If you're not signed in, then by default authorization fails unless you declare it as nullable. And which case, even if you're a guest, we will run the authorization check. Next, it's going to expect the, uh, idea that we are potentially working with.

Next, it's going to expect the, uh, idea that we are potentially working with. Alright, so let's give this a shot. Now, here's what I wanna do. If I go back to my routes file, let's get rid of this admin, uh, example. And actually on that note, we will also get rid of the gate right here. That was just a test. Okay? So now if we scroll back up, which one should we do first?

That was just a test. Okay? So now if we scroll back up, which one should we do first? How about this one right here? This determines whether or not we can show a particular idea. And you'll remember a couple episodes ago, it turned out that you could view an idea that you didn't create, which is a big security concern, right? Let's have a look. So once again, I'm signed in as Jane and we can view chain's ideas,

Let's have a look. So once again, I'm signed in as Jane and we can view chain's ideas, but yet, once again, if we manually adjust to the URI, she can now view an idea that she didn't create. Okay? So here's what we're gonna do within the show method, at least to start, we can still use the GATE API or the facade. So I can say let's authorize and now I'm gonna provide, uh, two arguments here. The first one is effectively the method name on the

and now I'm gonna provide, uh, two arguments here. The first one is effectively the method name on the corresponding policy. So let's go to idea policy. The method name is updates. All right, let's authorize an update for idea. Okay, so here's what's gonna happen when we run this. It's going to dynamically figure out what the corresponding policy is for the model. And it's just gonna follow a simple convention though keep in mind like everything, if you wanna manually configure or,

And it's just gonna follow a simple convention though keep in mind like everything, if you wanna manually configure or, or wire these things up, then you can do so, but usually by default, uh, conventions will work. So here's what Laravel is gonna do. It's gonna find the model and then it's gonna say, okay, I need to find a corresponding policy class for that model. So it'll look, hmm, is there an idea policy? Now let's go up a level. Is there a policies folder? Yes.

So it'll look, hmm, is there an idea policy? Now let's go up a level. Is there a policies folder? Yes. Is there an idea policy? Yes. Okay, this is the corresponding policy for that model, and that's what it's doing. It's precisely what that's doing. Okay? So now it says, okay, you wanted to authorize this particular ability. So I'm gonna send it through, or I'm gonna call the method. I will send through the current user,

So I'm gonna send it through, or I'm gonna call the method. I will send through the current user, and then I will send through the idea that you passed from the controller right here. So on ideal policy, can we update this idea? Well, let's find out. Update. Right now it says no, so it should fail. Let's come back, give it a refresh, and we get a 4 0 3 because nobody currently is authorized to view this idea, even Jane.

because nobody currently is authorized to view this idea, even Jane. So for example, if now if Jane tries to view even her own idea, that's gonna fail as well. Okay? So let's fix that now back to our editor. And what is the rule that determines whether or not, um, you can update or interact or, or modify or view, uh, this idea? Well, it's very simple. Uh, to start, we can say, look at the ID of the currently signed in user

Well, it's very simple. Uh, to start, we can say, look at the ID of the currently signed in user and check if it's the user ID for the corresponding idea. And if those match up, of course that means the current user who signed in created that idea, in which case, of course, you are allowed to modify it. So now if I switch back, if I refresh, Jane can see her idea. But if we try to view John's, I think, uh, then of course we get a 4 0 3.

But if we try to view John's, I think, uh, then of course we get a 4 0 3. Okay? So here's an important thing to understand generally, the, the API here is I identical to what we reviewed in the last episode, which means if you don't want a 4 0 3 instead you want a 4 0 4, then we can do the same, uh, response. For example, if they match, then we can use response allow, otherwise response deny has not found. All right? So now we're gonna get a

allow, otherwise response deny has not found. All right? So now we're gonna get a 4 0 4, All right? If we come back, we give this a refresh, you'll see this bump to 4 0 4 and uh, yeah, we can configure it just like we did in the previous episode. Great, but often you don't even need to do that. Okay, next, let's bring this back to what we had before. Uh, we do have a couple helpers.

Okay, next, let's bring this back to what we had before. Uh, we do have a couple helpers. So on any eloquent model, there's actually an IS method. So I can say if user is, and let's just take a look right here, what is is do determines if two models have the same ID and belong to the same table. Okay? So here's another way we could write this. If the user is the idea user, then they're the same people, right?

If the user is the idea user, then they're the same people, right? So let's go into idea and we can see we already have this relationship. So on idea, if I call user, that gives me the object of the user who created it. So I can just say, well, if these are the same, if the currently signed in user is the user who created the idea, then you're authorized. And yet this is functionally identical to what we have here.

who created the idea, then you're authorized. And yet this is functionally identical to what we have here. It's just a helper method that allows us to not, uh, reach for those properties or those, uh, database fields come back. Once again, we get a 4 0 3, but if we view her idea, then we do access it. Perfect. Okay? So now you have to decide if you need to draw a distinction between whether something can be viewed versus updated

So now you have to decide if you need to draw a distinction between whether something can be viewed versus updated versus deleted, right? So maybe you have some rule where, uh, okay, well if you want to view it, then here is our logic, but if you wanna update it, the logic is a little bit different. Okay? So now if you're imagining, well, what would be an example of where it's different? Imagine you're building some kind of project management app,

what would be an example of where it's different? Imagine you're building some kind of project management app, and for a project, anyone on the team, any members or any users on the team can view notices that are published to the top right, you can view them, but you can't create them and you can't update them. The only people who can update or create them are the managers of the team. All right? So now you can see there's a bit of logic there. All right? If I'm on a, if I'm on a team,

All right? So now you can see there's a bit of logic there. All right? If I'm on a, if I'm on a team, I'm just a regular person, then I can see the notice, but I can't necessarily create one, I can't delete it, I can't update it. So that's an example of where you might want multiple methods and abilities, uh, to determine what access rights you have. Got it. Okay, so if I bring this back to update, I wanna show you a couple other

Got it. Okay, so if I bring this back to update, I wanna show you a couple other little intricacies here. If I return to Idea controller, this is great, but if you review the documentation on the Laravel website, you'll see there's sometimes multiple ways you can do these things and it can be a little confusing, but they need and be, you can, you can choose one approach and stick with it. You don't have to learn every possible

one approach and stick with it. You don't have to learn every possible option if you don't want to. But I do wanna show you one thing on the currently signed in user. So let's pull in the off user. You'll see there is a can method and there's also a can. And notice those correspond directly to that can and cannot Blade directive that we learned about in the last episode.

and cannot Blade directive that we learned about in the last episode. So, and actually behind the scenes, that blade directive is deferring to the CAN method on the current user, right? It's kind of cool. So that means I could say I could do something just like this if the current user can update, excuse me, on post, if the current user can update this idea, then proceed. Or if they cannot, and let's just run this.

if the current user can update this idea, then proceed. Or if they cannot, and let's just run this. If you cannot update it, then we can say not authorized, just to show you that in situations where you don't want Laravel to perform the inspection and then throw the authorization, uh, exception, you can alternatively just do it yourself, uh, in situations where you need to proceed differently. Okay? So let's come back. Jane created this, she's authorized,

Okay? So let's come back. Jane created this, she's authorized, Jane did not create this. So our conditional, uh, returns true, and we say non authorized. Yeah, at this point, you can throw your authorization exception, um, log something, whatever it is, redirect whatever you need to do in those cases. But I find that often, uh, I don't need this. I I just call GATE authorized,

But I find that often, uh, I don't need this. I I just call GATE authorized, and then that's good enough for what I'm doing here. Now, uh, here's another thing. Let's imagine let's return to the policy here. And once again, notice the Laravel idea plugin for, for PHP. Storm is smart enough to just let me command click on that string there, and it takes me to where I need to go, which is so cool. Uh, anyways, let's imagine that there is, uh,

to go, which is so cool. Uh, anyways, let's imagine that there is, uh, that there is potentially separate authorization for whether you can view or create an idea, okay? So we might have one for view and we might have one for create. All right? So here's create, and yeah, maybe let's just say if the current user is the administrator, and remember we created this in the last episode, um, if

let's just say if the current user is the administrator, and remember we created this in the last episode, um, if that's the case, you can create it. Otherwise you can't. Okay? Now, you'll notice that sometimes for methods like this, there will be no corresponding idea. And here's what I mean, let's return to the controller and let's go to the Creates action. Yeah, we kind of wanna say this, well, gate authorized create idea, but I don't have an idea, right?

Yeah, we kind of wanna say this, well, gate authorized create idea, but I don't have an idea, right? We haven't created one yet. So in these situations though, we still need to provide something because if I leave it like this, think about it. Laravel doesn't know what the corresponding policy is. Don't forget a policy, um, has a direct line to an associated eloquent model. So if I do this, well, what is the model, right?

to an associated eloquent model. So if I do this, well, what is the model, right? We don't have one. So in these situations, just reference the, the model path as a string, like this idea class. So now Laravel can inspect this and see, okay, I need to figure out the corresponding policy for idea and then call create on it. That's the way that works, okay? So now in these situations, you won't even have an idea,

That's the way that works, okay? So now in these situations, you won't even have an idea, perfect, that will do the trick. So let's give this a shot. Let's go to ideas slash Create, and we get a 4 0 3, because now we've, and this isn't quite right by the way, uh, but we've decided in this example, uh, sitewide globally only an administrator can create an idea, which doesn't make sense for what we're building, but just to show you.

which doesn't make sense for what we're building, but just to show you. But if we change this, let's switch back, um, to user. And maybe, I'm not sure what Jane's idea or ideas if I come back, no, maybe it says three, four. There it is. Now Jane is considered the administrator, so she can access that, but nobody else can. Alright? So you get the idea, you have full control over your authorization.

Alright? So you get the idea, you have full control over your authorization. You can make it as intricate and complex as you need to, or you can simplify it to a simple method like update. Or again, if you want to do something like modify, that would be fine as well. Good. All right. So yeah, what I might do is have one for updates. We have a rule that determines whether or not you can update an idea,

We have a rule that determines whether or not you can update an idea, and then wherever is relevant, you can, you can reference that. So for example, I don't need this here, as long as you're signed in, you can access this. Um, as long as you're signed in, you can create one fine. But to show one, we should, we should authorize it to edit one, we should authorize that you actually created, um, this idea.

to edit one, we should authorize that you actually created, um, this idea. And just to show you, once again, I wanna drill this into you. Let's go to ideas slash four. I can go to edit. All right? If I go to one that Jane didn't create, she can edit that. So you, you have to be very smart about this. Make sure you're not accidentally exposing, um, access to data and information and pages that you should not. So once again, let's authorize the request,

to data and information and pages that you should not. So once again, let's authorize the request, give it a refresh, and now that's unauthorized. And don't forget, just like with, um, the standard gate closure approach, you can alternatively, if you, if it makes sense, apply these at the route level using middleware. So for example, right here, I can say, can you update the idea? And the idea is going to refer to the parameter name.

the idea? And the idea is going to refer to the parameter name. So that's, it's the same thing. It's the way we figure out what idea we are working with. Okay? Exact same thing. Give it a refresh. And now, uh, it's forbidden, but she can edit her own ideas. All right? So if you like this approach, you can do that as well. But for now, we're gonna stick with the controller approach. All right, what about updating? So can I manually hit this?

But for now, we're gonna stick with the controller approach. All right, what about updating? So can I manually hit this? Remember, it doesn't have to go through the browser. Can I do it from the command line and make a a patch request here? Yes. In that case, is it possible that you could update somebody's, uh, somebody else's idea? Yeah. So let's make sure that no, you can only update the idea if you're the one who created it in the first place.

you can only update the idea if you're the one who created it in the first place. And then finally, the exact same thing is going to be true here. Alright? And you know what? That's basically all you need to know about authorization at this point in your learning. So if you feel comfortable, let's move on in the next episode.

let's move on in the next episode.