Learn Inertia
This episode is for members only

Sign up to access "Learn Inertia" right now.

Get started
Already a member? Sign in to continue
Playing
26. Basic authorization

Episodes

0%
Your progress
  • Total: 2h 20m
  • Played: 0m
  • Remaining: 2h 20m
Join or sign in to track your progress

Transcript

00:00
Authorization is a really important part of any application you build and this is just authorizing certain actions for users. For example, can a specific user post a comment or can a user update a comment if they own it? You may have
00:16
worked with this before if you've already been working with Laravel. What we're going to do though is look at how we can handle this in inertia on the client side in the easiest way possible. So to get started we're going to go out and create a policy for our posts. So let's go ahead and make a policy here
00:36
and we'll call this post policy and let's head over to that post policy and if you're not familiar with policies let's take a look at what we mean. So we don't have any kind of update functionality at the moment so we just want to know can a user create a post and we're going to create a condition in
00:55
this method around whether the currently authenticated user that will get passed into here can actually create a post. Now let's use the email verified at column as an example. Basically we want to say a user can only create a post if they have verified their email. To do this we just want to go ahead and
01:15
grab the user and say has verified email and that's of course going to return true or false. In the case of these that I have logged in it's going to be false so I shouldn't be able to post a comment if I haven't verified my email. Now to use this policy within a Laravel application we're going to come over to
01:36
the comment store controller and just up here probably before the validation as you can do this yeah let's do this before the validation we're going to go ahead and say this authorize we're going to give the name of the method that we've got here create and if we were dealing with a specific post that
01:56
we wanted to check we would actually pass the post model in. In our case we're just dealing with the overall post model and can we create one of those. Now we haven't registered this policy yet so over in auth service provider let's go ahead and do that now inside of policies for the key here we're going to give the
02:14
model name and then for the policy we're just going to give the fully qualified namespace to the policy. So now that we've added this authorization in we shouldn't be able to actually post anything we can either keep an eye on our network tab for this or with inertia it should just pop up with an error. So
02:32
let's go ahead and try to post a comment and sure enough we get this sort of modal window which we're going to talk about in the next episode with 403 this action is unauthorized. So we've successfully implemented authorization here to stop users who haven't verified their email from posting however the
02:51
only issue is we can still see the form on the front end and because we're working with a view application on the front end how are we going to authorize this or check this on the front end. Well there are lots of different ways that you can do this but for the majority of applications the easiest thing to do is
03:08
just pass this data down to your page so you can access it. So what do we mean by that? Let's go over to the comment index controller and as well as the post we're going to pass down an object called can or an array in this case and then inside of here we can just give a list of various permissions. In this case we want
03:28
to know whether we can create a post or create a comment whatever we decide to call it and then we can go and grab the currently authenticated user and remember that user might be unavailable if we are potentially allowing users to be unauthenticated so we can use the null safe operator. For us I've added the
03:47
middleware here for this particular page because we do actually need to be signed in to access it. Then we're going to go ahead and say can and then we're just going to do pretty much what we did over on the comment store controller. We want to know whether we can create a post and now we will have this can object
04:07
technically when it gets into view that we can read the permission from. Now you can add these absolutely anywhere so for example if you were wanting to edit a particular post over in the post resource you could add the same thing in here so you could say can and then edit so this can go anywhere and this is the
04:31
most simple way that you can do this. Other solutions do exist but this is a really great start. Okay so now that we've passed this down let's go ahead and access it over in the comment index page so let's go over to that and we're going to go up to where our form is here and actually just before we do that
04:49
let's go ahead and make sure we accept this in without now props so can is going to be an object so let's go down to our form here and we don't want to show any of this if we cannot do that so we're gonna say can create post. Okay let's head over and there we go it's disappeared so we cannot now see that
05:15
form we know that we've got the authorization set on Laravel's end so there's no way we can post a comment. Let's go ahead and verify my email by manually setting this to now in the database and let's head over and give this a refresh we can see it and sure enough we can go ahead and post.

Episode summary

In this episode, we dive into the basics of handling authorization in our application. We start by outlining why authorization matters—essentially, it's about ensuring that only users who are supposed to can perform certain actions, like posting or updating comments.

We get hands-on by creating a simple policy (using Laravel's policies) to control who can create a post. For this example, we decide that users must have verified their email to be allowed to post. We walk through setting up this policy, wiring it into our controllers, and making sure it gets registered properly so Laravel recognizes it.

Once the backend restriction is in place, we test it out—when a user without a verified email tries to post, they see an error. Cool, but there's a catch: even though they're blocked on the backend, the form is still visible on the frontend, which isn't ideal.

To fix this, we show how to pass down the user's permissions from the backend to the frontend using Inertia.js. We update our controllers to send a simple can object that tells the frontend what actions the user is allowed to perform. On the Vue side, we use this data to conditionally render the post form only if the user has permission.

By the end of this episode, we've got both backend and frontend checks in place and the UI now matches the user's permissions—if your email isn't verified, you don't even see the form. Simple, but super important for building a secure app!

Episode discussion

No comments, yet. Be the first!