Now, the last thing I care to research for this series is basic authorization. For example, is John Doe authorized to delete this particular contact? Now, presumably, yes, because here, this would be all of the contacts for John Doe, but maybe the permissions are different. John Doe can see the contacts, but maybe he can't delete it. At least for this little example. Okay, so I had a look here through the source code, and it doesn't look like there's a good example of how to handle authorization here. However, this is something I've reviewed in the past, and it seems like there's kind of a common way to tackle it.

However, this is something I've reviewed in the past, and it seems like there's kind of a common way to tackle it. So let's have a look. Right here is the edit action, which is responsible for this page. Notice right there. Now, if you think about it, if we want to include policy information—php, artisan, link, Policy—what is a good way to pass that to your view components? And a good way is to simply pass it as a prop, like anything else. So, for example, can the current user delete User? Now, if you're familiar with Laravel's Gate functionality, you could use Gate::allows,

So, for example, can the current user delete User? Now, if you're familiar with Laravel's Gate functionality, you could use Gate::allows, or you can even do auth()->user()->can, and then you reference the policy name. Here I'm going to be super generic, but yeah, you could do something like this. Maybe you could check a certain role or relationship, or why don't we just say, if the user is an administrator or has a particular ID, they have permission to delete a User, otherwise you don't. Again, a little silly in this example, but it's enough to get the idea across. Let's go ahead and accept this as a prop within contacts/edit. We'll come on down here, and yeah, we'll do it right here.

Let's go ahead and accept this as a prop within contacts/edit. We'll come on down here, and yeah, we'll do it right here. Think of can as your authorization object. Okay. So, if we come to Chrome, give this a refresh. Let's have a look. All right, edit, and sure enough, can we delete a User? No. We don't even have a policy called deleteUser, so it returns false. But we could quickly create one, and I'll just do it in AuthServiceProvider.

We don't even have a policy called deleteUser, so it returns false. But we could quickly create one, and I'll just do it in AuthServiceProvider. Yeah, we could say Gate, pull in the facade. Let's define one for deleteUser. This will accept the currently signed in User, and again, let's just return true to start. All right, come back, refresh, and this time, sure enough, it's set to true. Okay, but yeah, in real life, you're checking some kind of relationship, maybe even for a simple app, the ID. So, for example, maybe the User with an ID of one is the only administrator in the entire app, and you know, ID of one is the only admin.

So, for example, maybe the User with an ID of one is the only administrator in the entire app, and you know, ID of one is the only admin. Now, I think John Doe probably has an ID of one, so this should work. Yeah. But maybe if it's two, come back, have a look, now it returns false, because John Doe has an ID of one, but only the ID of two has access. Again, this is fine for really simple apps with only one administrator, or you can even do something like an all-encompassing like, or admin. That can often be useful. If only the administrator can perform certain actions, keep it generic.

That can often be useful. If only the administrator can perform certain actions, keep it generic. So then you'd come back to your controller. If you can administer, then we'll pass it through. Anyways, once again, refresh, and here we go. Okay, so now you have your authorizations that were defined on the server side through policies, and they're now being passed to your client side through a view component, which means now, in your view component, we've accepted the canAuthorization object, and you can reference it anywhere you want. So for example, here's the button to delete a contact, which would be right down here.

and you can reference it anywhere you want. So for example, here's the button to delete a Contact, which would be right down here. Okay, so let's conditionally display that if you can administer. CanAdmin, and then it looks like we also show the button if it has not been deleted, of course. Okay, so come give it a refresh, and we see it. John Doe is the admin. But if we tweak that, like we did before, one more time, now we don't see it, because John isn't the administrator. All right, and believe it or not, that's the basic shape of authorization.

John isn't the administrator. All right, and believe it or not, that's the basic shape of authorization. So here you can see we're passing it at the top level for the signed-in user, but you can also do it within a collection. Do we have a good one here? Yeah, even things like this. So this is where you would fetch all contacts on the page, like this. So you can fetch all of them, and then transform the collection, and also include things like this. So if you have an authorization like deleteUser, you could even use the Gate facade, like Gate,

this. So if you have an authorization like deleteUser, you could even use the Gate facade, like Gate, and if you don't want it on the signed-in user, you could say forUser. So whatever the relationship between a Contact and a User is, maybe a Contact is a User, I'm not sure. But yeah, you would just pass that, things like this. And you might even have a few, if they are unique. Now you'll have unique authorization for each User in your result set. All right? And that's authorization using Laravel, but passed to your view components.

All right? And that's authorization using Laravel, but passed to your view components.