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
12. Team roles and permissions 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
Let's dive into how our roles and permissions work within Teams by going ahead and assigning the Team Admin role to a user when they first sign up. We know that we did this over in the User Observer, so if we just open that up we know that we created a team for the user,
00:17
associated that with their current team, but somewhere in here we want to give them Admin role for that team that we've just created. How do we do that? Well let's go ahead and write a test for this first of all over in our User Observer test and then we'll go ahead and fill this in. Okay so let's say it gives Admin or it gives the Admin role to the personal team,
00:43
something like that, and let's go ahead and get started. So let's create this user out and obviously that's going to create a personal team and we can include the name. In fact we don't necessarily need to include the name in here so let's just keep this as short as possible by not and we want to go ahead and expect the user to have a role, so we want to say has role
01:09
Team Admin to be true. Now the question is how do we know that this Team Admin role relates to the current team that this user is in? We'll take a look at that in just a second but let's run this test first of all just to see that this is working. So let's go into our Feature Observers test and run this User Observer test and of course at the moment we expect this to be false but this
01:34
is pretty much how we check if a user has a role. Okay so how do we go ahead and fill this in? Well let's go over to our User Observer and let's fill this in just here. So to do this we could do this either after we've associated this and save this, it doesn't really matter. We're going to say User Assign Role Team Admin. Now once again how do we know that this Team Admin role is getting
01:59
assigned to the current team for the user? Let's go ahead and run this test again and we're going to get a couple of issues here. So the first one is we've got a few failed tests and that is that there is no role Team Admin for Guard Web. Now the reason that this is happening is because we've seeded our database but the tests don't have access to this seeder and we've not specified
02:21
that we want these to be run. So what we can do is head over to the pest.php file under our test directory and for all our feature tests we could add in a before each hook to seed our database. We're pretty much always going to need these roles and permissions. To do this we can just say this seed and then we can just pass in all of the seeders that we want to run. So we can run our
02:45
admin role seeder and we can run our member role seeder as well. So then at least now we have them as part of all of our tests. Let's run this user observer test again and now that we've fixed that up we would probably assume that this would now work but you can see that it doesn't. What we get here is a null value trying to be inserted into current team id under model has roles. Now
03:11
the way that this package works and the reason that I'm explaining it like this is that globally what we need to do is within middleware set which team we are a part of so when that gets filled in in the database anywhere in here or in the model has roles this fills in the current team id which can then when we use has role hook this up and check that we have a role for that particular team.
03:36
So let's go ahead and build that middleware out and then see the difference. So let's go and create out some middleware here in our application and let's call this team's permission. It doesn't really matter what we call this but let's open this up and see what we need to do. So essentially within this package we have a set permissions team id function so that will take in a integer of the
04:00
current team id that we want to associate or add to the database whenever we run or whenever we associate a user with a particular role. So this is like a global thing that we set on every request to our application to fill these values so we don't need to manually do it. So what we want to do is within this middleware first of all check that we are authenticated because we're going to
04:22
add this as global middleware. So let's check and assign at the same time that we actually have a user. If we do have a user we're going to set the permissions team id to let's guess the current team id. The reason that we set it to the current team id is because if we switch teams this then has to run again as part of our middleware to update this. So then when we switch over to
04:46
another team it knows which team we're in so we can check the correct permissions. So think of this is just like a global thing that says this is the current team we're in so any permissions that we check will be in relation to the team that we've given here. Okay so let's add this middleware to do this we need to go over to bootstrap and app under the framework and down here under middleware
05:08
we just need to add this in. So we're going to say middleware and this is for web and we want to append on so let's use append to append on that team permission middleware that we've just created finish that off and now this middleware is global. This middleware will also be run during our tests so now when our user observer runs this should pick this up. Now it might not so let's just see
05:36
what happens when we run our tests and we'll fix that up otherwise. Okay yeah so it still hasn't worked now this middleware will run during feature requests when we send an HTTP request to our application but it's not going to run in things like our user observer test because we're just making a request to Eloquent here to create our record so actually what's going to happen here is
06:00
it's still going to fail. So what we want to do is anywhere within our code like in the user observer where we're assigning a role first time we want to go ahead and set in here that we're in that team so in here this is a good candidate for specifically setting team id in here before we assign that role. So let's go through this again we attach the team the personal team to the user
06:25
we associate it with them and then we go ahead and set that we are part of that personal team now globally and then when we assign this team admin role this will insert team admin in the database but along with the id of the team so we know which role relates to which team. Okay let's finally go ahead and run our test again and we get green. So let's go through this in the UI
06:49
and then we'll see this in the database and hopefully it'll make sense. So let's go over to our team user get rid of this let's go over to our teams and get rid of these although we're in a bit of trouble here because we've got things hooked up so let's just go over to our user and get rid of current team id and let's delete these teams delete that user and let's register an account
07:15
from the start. So let's go over to register here register out a new account now what this should now do is create a personal team but also attach this admin role to that personal team under that team id so let's hit register there we go so we've got a personal team let's go back over and have a look so the team's been created I am obviously part of that team but let's go over to
07:38
the model has roles so you can see here that the user id of three which is me under the current team id of four which is the new team that's just been created has the role of one which is admin so now when we do a check like is this user a team admin or does this user have permission to do something it will do it within the context of this current team so now that we've got this
08:05
done let's just take a real quick look at using has role again just directly within our dashboard or something like that so let's go to our web routes and we'll just die dump here just to double check this so we're going to say auth user has role team admin now of course we expect that to be true let's go over and switch us over to another team and see that this returns false and
08:32
then you'll get the idea that it comes within the context so let's go over to our teams here and let's create our new team again just manually in the database that's id of five so let's hook us up to team five and let's switch over to that team so let's go over to Cocos now when we go ahead and try and die dump this we've created this but we've not assigned any roles so you would
08:57
expect this now to be false so now that we've got that middleware in there that is globally running to set that we are part of a team it will always check the roles and permissions in the context of that team so hopefully that makes sense as we go through this will start to make a little bit more sense and we now pretty much have that global check for the team that we're currently in

Episode summary

In this episode, we dive deep into how team roles and permissions work in our application. The goal here is to make sure that when a user first signs up and creates their personal team, they're automatically assigned the Team Admin role for that specific team. We walk through writing a test to check this behavior, run into some common issues, and then resolve them.

You'll see how we seed the database with the necessary roles data and discover why just running middleware globally isn't enough—especially when dealing with things like observers and database tests that don't go through HTTP requests. That's where we learn that, in places that aren't part of the usual request cycle, we need to make sure to set the current team ID manually before assigning a role.

We then build a middleware to globally set the current team context for each request, making our roles and permissions system team-aware. Once this is all set up, we try things out in the UI and directly in the database to confirm that role assignments are linked to the correct team IDs. Plus, we test how switching teams changes what permissions the user has, confirming that our middleware keeps everything in the proper context.

By the end, you get a pretty strong understanding of how roles and permissions are managed per team context—so when you check if a user is a team admin, it checks against the right team every time!

Episode discussion

No comments, yet. Be the first!