Laravel Actions
This episode is for members only

Sign up to access "Laravel Actions" right now.

Get started
Already a member? Sign in to continue
Playing
07. Authorizing actions

Episodes

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

Transcript

00:00
The way that we've set this URL up here is very common when we work in a restful pattern.
00:05
We have a resource under this user section, which is ID of one, which is what we've looked at, and then the kind of resource group underneath that, which is ordered. Now, this is a really good way to structure things. It makes things really nice and clear.
00:19
But the only issue is we could technically, at the moment, at least, without create order action, create an order on behalf of any user. There's no kind of authorization here to say, is the current user who is trying to create this, this user that we've passed in?
00:35
So I've got another user just over here in the database. What we shouldn't be able to do is pass an ID of two in and create an order on Mabel's behalf. Let's just test this out, first of all, by just heading over to our dashboard and just modifying this very slightly just to go back to slash users slash two,
00:54
and then orders like so. And you could post this through with some kind of REST client if you wanted to test it as well. So if I just go back over to our dashboard and I hit create order, sure enough, I'm signed in as Alex.
01:06
But what I've now done is created a order under Mabel's account, which is not great. So we need some authorization to protect against this. And that's exactly what we're looking at in this episode. So let's head back over to the dashboard.
01:20
And we're going to go ahead and just leave this as it is for now and open up our action. So as you'd imagine, following the same kind of pattern that we've already seen, what we need to do here is implement a method which will be invoked to authorize this request. So as an example, let's go ahead and create out an authorize method.
01:39
Into this, we actually get in a action request specifically from that package. And we're just going to name this request. And from this, we need to return a Boolean, whether this has been authorized or not. Let's just pull the namespace in for the action request.
01:55
And let's just explicitly return false in here just to test this out. OK, so if we come over and hit create order, there we go. We get a standard Laravel error page with a 403 telling us that this action is unauthorized. Now what we need to do is just apply the logic to check, well,
02:11
can the currently authenticated user do what we're asking? Well, let's figure out, first of all, how we can get the root model binded thing in here. Because we're going to need that to compare against the currently authenticated user. Let's die dump here on the request.
02:29
And we're going to go ahead and say root and user. Now what that will do is it will pluck out the root model binded thing that we've passed in. Let's come over and just give this a refresh. And there we go.
02:40
We get the user that we're trying to perform this action on. So now what we can do is just go ahead and say request user, which is the currently authenticated user. Grab their ID and compare this to using request root user and ID.
02:57
So basically, is the currently authenticated user the user that we're passing through here? Well, in our case, it's not. So let's go back over to our dashboard, hit create order. It's unauthorized.
03:11
Let's just come over to our dashboard and manually change this to one, which we know is the user we're currently authenticated as. And sure enough, that works. We're not redirecting anywhere.
03:20
But we could just as easily go ahead and add this in. So that works nicely. Let's bring this back to use our actual root here. And let's go over to our create order just to go ahead and return back when we hit on that.
03:34
Okay, great. So now if we head over to our dashboard, we are now protecting this root against checking the request and the user that's passed in with that request to the currently authenticated user.

Episode summary

In this episode, we’re diving into how to securely authorize actions in a RESTful setup, specifically focusing on making sure users can only perform actions on their own resources. Up until now, anyone could technically craft a request to do something like creating an order on behalf of any user—obviously not what we want!

We start by demonstrating the problem: by tweaking the user ID in the URL, it's possible to create an order for a different user—even if you're logged in as someone else. This clearly needs fixing.

To solve this, we implement an authorize method in our action. At first, we just make it return false to check that unauthorized actions are blocked (which results in a nice 403 error page). Then, we enhance the method to compare the currently authenticated user to the user referenced in the URL. If they match, we allow the action; if not, it's blocked.

We wrap up by confirming that users can now only create orders for themselves, not others. This secures our resource endpoints and demonstrates a clean pattern for adding simple authorization checks to your application actions.

Episode discussion

No comments, yet. Be the first!