Sign in Get started

This episode is for members only

Sign up to access "Laravel Teams" right now.

Already a member? Sign in to continue

Playing

14. Testing team permissions through HTTP requests

Episodes

0%

Your progress

Total: 4h 36m
Played: 0m
Remaining: 4h 36m

Join or sign in to track your progress

01. Introduction and demo

02. Setup with Pest

03. Building the user teams relations

04. Creating a personal team when registering

05. Leaving all teams when an account is deleted

06. Tracking the current team

07. Showing team details in the UI

08. Switching to another team

09. Authorising team switching

10. Updating a team name

11. Basic roles and permissions setup

12. Team roles and permissions middleware

13. Authorising current team updates

14. Testing team permissions through HTTP requests

15. Leaving a team

16. Displaying team members

17. Making team members look better

18. Removing a team member

19. Preventing self removal from a team

20. Storing invitations

21. Validating invitations

22. Authorising team invitation creation

23. Displaying invitations

24. Revoking invitations

25. Sending an invitation email

26. Accepting an invitation

27. Displaying a modal to change a member’s role

28. Updating a member’s role

29. More authorisation and checks for role changing

30. Fixing up the email sending test details

31. Fixing and validating email addresses for invites

32. Tidying up @can directive checks

33. Detaching roles when removing users

34. Adding an extra layer of protection to the team middleware

35. Getting related models through teams

36. Building a helper to access the current team

37. Getting all related models through all teams

38. Creating new teams

Transcript

00:00

Based on what we know about how we set the current team with that set permissions team ID function from the sparsity package, let's go ahead and write a test to check if we can update a team if we don't have permission. So we shouldn't be able to update a team without permission. And of course we covered that over in the team policy just here where we said user can update

00:22

team. Remember these permissions are attached to roles which are attached to the team itself. Okay let's go ahead and write out a test how we normally would and we'll see how this doesn't work and how we can fix it. So what's the test going to be? Well cannot update a team without permission. So we can't go ahead and update this if we don't have permission as we've already seen.

00:47

Okay so to test this let's go ahead and create out the user who will be going ahead and actually making the update. Now remember this user by default will have a personal team and they will be set as a team admin. But let's go ahead and also assign this user or attach this user to another team but we won't specifically give them permission to do anything. Let's call this another

01:10

team. So we use our team factory to go ahead and create this out. Okay so what we basically now want to do is acting as this user we want to send a patch request down to that route. So let's go ahead and put in that team update route passing in another team. So we're trying to update this other team and we'll go ahead and pass down the name here that we want to change for a new team name.

01:38

Now because over in this route we are now using the update method from the policy where it's checking this we would expect to get a forbidden. So let's say assert forbidden and let's see what happens. So let's specifically run this test just so any of the others that might fail or don't get in the way. So let's say pest and filter and we'll filter by this name. Okay so we can see that this

02:05

failed let's have a look. So it looks like we get a 302 redirect. So what's actually happening here? Well remember that when we make a HTTP request within our tests this is going to include the team's permissions middleware that we created earlier. So this middleware will actually be invoked as part of that test request. What that means is because we are acting as a user within

02:30

our tests this is technically going to assign us to the team that we currently have. So for this user here within this test even though we're making a request to another team this is still going to assume that we're within that team. Now there are loads of different ways that we could configure our application so this isn't the case but since this works the best way we basically just need to

02:55

adjust our tests to manually set which team we are a part of. So basically faking this middleware. Now we're not actually going to fake the middleware but what we are going to do is use the without middleware method on this. We're going to pass in the team permission middleware that will exclude the middleware being run for this particular test and then what we can do up here is we can

03:16

manually use the set permissions team id to that another team id. So basically we are saying well this is what happens in the middleware normally so we're going to fake it within our test but then we're going to exclude the middleware when we actually run this. Let's go ahead and run this test again and you can see sure enough we get a green so we're going to have to do this in multiple

03:36

places where we need to basically simulate that we are a part of a different team. There are other ways to do this but I found this is the easiest way and basically within tests anyway all we're doing is just modifying how this request is made so doing this and then just excluding the middleware isn't too much trouble. Okay let's just finally run all of our tests just to make sure and yeah we're all good.

Episode summary

In this episode, we're diving into how to properly test team permissions by simulating HTTP requests in our test suite. The main goal here is to verify that a user who doesn't have the correct permissions can't update a team. This ties back to the team policy we set up earlier, where only certain roles are allowed to update a team.

Here's what we do step-by-step:

First, we write a test that tries to update a team as a user who shouldn't have permission. The user has their own personal team (where they're admin) but is also attached to a second team, this time without any special permissions.
We then make a PATCH request to update this second team and assert that the response should be forbidden.
When we run the test, we notice it surprisingly fails with a 302 redirect. That's because our team's permissions middleware is getting invoked during the request, and by default, it thinks we're part of the team being tested.
To get around this, we adjust our test: we use the withoutMiddleware method to exclude just the permissions middleware for this test, and then manually set the team context with setPermissionsTeamId. This simulates the effect of the middleware without actually running it.

After making these tweaks, we rerun the test—and success, it passes! We mention that this pattern will come up in other tests when simulating being part of different teams. There are other ways to handle this, but this approach is straightforward and effective for our needs. We round off by running all the tests together to make sure everything is still green.

So, after this episode, you'll know how to reliably test user permissions around teams and tweak your tests to simulate different team contexts without headaches.

Episode discussion

No comments, yet. Be the first!