Laravel Teams
This episode is for members only

Sign up to access "Laravel Teams" right now.

Get started
Already a member? Sign in to continue
Playing
34. Adding an extra layer of protection to the team middleware

Episodes

0%
Your progress
  • Total: 4h 36m
  • Played: 0m
  • Remaining: 4h 36m
Join or sign in to track your progress
01. Introduction and demo
4m 49s
0%
02. Setup with Pest
4m 2s
0%
03. Building the user teams relations
6m 5s
0%
04. Creating a personal team when registering
6m 3s
0%
05. Leaving all teams when an account is deleted
3m 55s
0%
06. Tracking the current team
4m 50s
0%
07. Showing team details in the UI
2m 55s
0%
08. Switching to another team
7m 24s
0%
09. Authorising team switching
6m 53s
0%
10. Updating a team name
10m 48s
0%
11. Basic roles and permissions setup
5m 26s
0%
12. Team roles and permissions middleware
9m 18s
0%
13. Authorising current team updates
3m 43s
0%
14. Testing team permissions through HTTP requests
3m 58s
0%
15. Leaving a team
10m 50s
0%
16. Displaying team members
8m 42s
0%
17. Making team members look better
5m 3s
0%
18. Removing a team member
15m 18s
0%
19. Preventing self removal from a team
4m 7s
0%
20. Storing invitations
13m 31s
0%
21. Validating invitations
6m 38s
0%
22. Authorising team invitation creation
6m 22s
0%
23. Displaying invitations
3m 16s
0%
24. Revoking invitations
12m 46s
0%
25. Sending an invitation email
13m 6s
0%
26. Accepting an invitation
12m 22s
0%
27. Displaying a modal to change a member’s role
10m 31s
0%
28. Updating a member’s role
9m 5s
0%
29. More authorisation and checks for role changing
10m 14s
0%
30. Fixing up the email sending test details
49s
0%
31. Fixing and validating email addresses for invites
1m 32s
0%
32. Tidying up @can directive checks
3m 25s
0%
33. Detaching roles when removing users
5m
0%
34. Adding an extra layer of protection to the team middleware
6m 35s
0%
35. Getting related models through teams
5m 37s
0%
36. Building a helper to access the current team
10m 47s
0%
37. Getting all related models through all teams
7m 15s
0%
38. Creating new teams
13m 7s
0%

Transcript

00:00
So while this is probably never going to be a problem unless we manually adjust the database, we're now going to add an extra level of protection to our Teams permissions middleware.
00:10
Let's just remind ourselves of what that looks like. So let's go over to our middleware here. And what this does is obviously it runs for every single web request. It will go ahead and as long as the user is authenticated, it will set the global team ID.
00:25
So every action that's taken within this web request will be in the context of that specific team. Now, what happens if for whatever reason the user does not belong to the team that has been set in the database? Now, nowhere within our code will that be set incorrectly. But if, for example, this data is accidentally updated within an admin panel or manually within the database,
00:50
it would be a good idea to just cut the request off at this point. Let me show you what this looks like and then we'll go ahead and fix it up. So at the moment, we've got Alex who has a personal team of 15 with the ID and Mabel with 16. What I mean is if this value gets changed for some reason to a team that Mabel doesn't belong to,
01:10
and I've gone ahead and cleared this out so only we belong to our own teams, then what's going to happen? Well, if we go over here and give this a refresh, you can see that sure enough, we are switched over to that team. Now, that's not much of a problem because we can't see any of this stuff because we don't have permission to view it. So it's not a problem in that respect, but we might still be able to see any confidential information that's posted as part of that team.
01:35
So let's go and write a test for this and get this fixed up. OK, so what do we need to do here? Well, in fact, let's go ahead and write the code out for this first of all, because it's probably quite easy to demo it this way, and then we'll just add a really simple test. So what we want inside of this, as long as the user is authenticated,
01:55
is just to check if their teams doesn't contain the team that we're trying to work with, which is the user's current team. So let's add that in there. Then let's go ahead and abort with a 403. We'll refactor this in a bit once we've written our test, but this should be enough now to just very basically solve the problem. So if we go over and switch Mabel back over to my team and give that refresh,
02:20
they just can't access this page or any of the pages while they're within that team context. Now, this will be kind of stuck in this state forever. So you might want to, instead of just aborting, go ahead and update to one of their other teams or something like that. I'm just going to abort it for now because it's highly unlikely that this is ever going to happen.
02:39
But you can go ahead and do whatever you want in here to get around this. OK, so we know that this is working. Let's go and just switch this user back over to 16 and we'll go and write a test for this. So let's go ahead and create our new test for this. So let's say PHP artisan test test. And although we're not directly testing the middleware, I'm going to put it under a middleware directory.
03:01
So it kind of makes sense. So let's say teams permissions test. And we can even write a test to make sure that this gets assigned properly as well. OK, so over in our test directory under features and middleware, let's go ahead and open this up and let's go ahead and test this. So we're going to say it aborts the request if the user does not belong to the team.
03:28
OK, let's go ahead and do the setup and get this working. So we're going to need a user who doesn't belong to a team that we're trying to access. So let's go ahead and create out a user in here. And they're going to have a personal team, but we can create another user in here that also has a personal team.
03:48
Let's go ahead and say user or we could create the other user first. Then we could manually set the current team ID while we're creating this user who doesn't belong to that team as the another user's current team ID. So exactly like what we've just done in the database. But of course, within our tests. OK, let's go ahead and run this test.
04:09
So tests and feature. Let's run middleware and teams permissions test. And yeah, that looks good. But obviously we haven't asserted anything. Now, like I said, we're not directly testing the middleware. We're just going to make a request to any of the pages on our site. So let's just remind ourselves we have some sort of homepage or we could use the dashboard in this case.
04:33
I think that's probably a good idea. So let's just name dashboard. So we're going to go ahead and say acting as this user. Let's make a request to. So let's go and just get the dashboard route. And we're going to assert that this is forbidden like we've done.
04:53
And I think that should be just about it. Let's go ahead and test this out. OK, so we do get a failure here and that isn't right because, of course, we've gone ahead and aborted with the 403 here. So let's have a look. OK, so what's happening here is we are setting the current team ID when we create the user. The user observer will be setting that afterwards. So we'll end up back in our own team.
05:16
So let's do this in a slightly different way. So let's grab the other users current team and let's just associate this in the same way. So let's say user current team and associate. Let's associate that with the other users team and then go ahead and save that. OK, so now that user should now be acting under that team and that should be saved to the database.
05:37
Let's go ahead and run that test again and we get green. Great. So let's just for clarity, get rid of this. And obviously that should fail. Brilliant. OK, let's go ahead and refactor this. So a much easier way to do this would be to say abort if and then go ahead and paste that in and then pass in the status code that we want. We still get a pass for that. Or in this case, it's probably a little bit clearer to say abort unless the team doesn't contain that or the team contains that.
06:09
So abort unless the users team contains the current team. It's entirely up to you which way round you do it. Either way, it is going to pass. OK, there we go. Perfect. So we've gone ahead and fixed that problem. And now we just get a 403 if the users ID for the current team has been set and they do not belong to that team. Like I said, this is probably very rare that this is ever going to happen, but it just adds an extra layer just in case.

Episode summary

In this episode, we're adding an extra safety net to our Teams permissions middleware. Even though it's unlikely, sometimes the current team for a user might get set to a team they don't actually belong to—usually only if someone changes things manually in the database or admin panel. To guard against this, we update our middleware to check: if a user's set current team isn't one of their actual teams, we abort the request with a 403 error.

We walk through what this edge case looks like by trying to swap a user's current team to something they shouldn't have access to, showing how the app behaves. Although users won't be able to see restricted content, it's best to cut off the request completely to prevent potential privacy leaks.

Next, we write a test that specifically sets up this problematic scenario, then makes sure our middleware correctly stops the request. Once our test is passing, we make a quick refactor to clean up the code, and show a couple of alternative ways to write this check.

By the end of the episode, we've strengthened our middleware so a misconfigured or tampered database can't accidentally reveal sensitive team data to the wrong user. It's a rare situation, but it's always good to be a little extra safe!

Episode discussion

No comments, yet. Be the first!