Playing
12. Authorising other models

Transcript

00:00
Let's change things up and do a couple of extra things. The first thing that we're going to do is broadcast to another channel. So as well as broadcasting this globally to the dashboard,
00:11
we're also going to broadcast it to a specific order page. Think about if you had a user sitting on an order page waiting for a status update, it would roll in there as well as maybe a global notification, kind of like what we've done here. The second thing that we're really focusing on here is how to authorize in a slightly different
00:31
way if we are listening on a specific model's channel. So let's go ahead and change things up. Before we do anything, let's create out a new route here and we will create out a orders route. We'll just do this all in line for now.
00:46
And let's take an order into here and render out an order view. So if we go ahead and make out a view here and we'll call this order. And we're going to pass that order that we get through in here down to that view so we can do something with it.
01:04
So let's pass that order down. Just imagine we're building out a page where the user can see a specific order. OK, so let's go ahead and duplicate this tab over and we'll go over to orders slash one. And we shouldn't see anything.
01:17
Let's go and just grab our dashboard template and we'll paste it over to that new order.blade.php file that we created. So up here, we're going to say something like the order ID. Let's output that.
01:31
And now the user should have an orders page that they can listen on. And we're going to be doing exactly the same thing as we did here. We're listening to multiple channels. OK, let's head over to our channels file and we'll define out a new
01:43
channel in here specifically to listen on an order. So we'll call this orders and let's go and specify this as order ID. So it's a little bit clearer. We'll pick that up inside of here.
01:56
We know that because we're going to authorize on a private channel, we'll always get the user ID in here. OK, so what I'm going to do is always return true at the bottom here and then just use defensive programming to return false if this order doesn't belong to this user.
02:12
So if a user is trying to listen on an order that they don't own, don't authorize them. So how do we do this? Well, we could go ahead and fetch out the order model using the order ID and compare the order ID's user ID to this user.
02:29
So to do this, we can grab the user's ID and if it doesn't equal and let's fetch find or new because find or new will always give us back an empty ID if it doesn't exist. And we pass in that order ID. Then we can grab the user ID from that.
02:48
Now, if that doesn't match, we're going to return false and we are not going to authorize them. And feel free to implement any method here to check this. We just want to make sure it works. OK, so now that we have defined the channel, we can go over to our events that we created.
03:05
So order dispatched and we can provide a different channel in here. So remember, we can define multiple channels. So we also want to broadcast on orders and then we need the order ID. So let's just pass in the order ID.
03:19
OK, we'll do the same thing for the other event that we defined order delivered. And we'll just paste this in here. OK, great. So we're now broadcasting on two different channels.
03:29
Let's go over to our orders page and just tidy this up and then we should be good. OK, so we're listening on orders. But now we need to replace this out with the order ID that we passed down to this template. And we're listening for the exact same events and doing exactly the same thing.
03:46
OK, let's see if this works. And if we've made any mistakes, we can fix it up. So we're going to go ahead and broadcast this. We'll head over.
03:53
We should see both of these roll in. And you can see they both come in here on different channels. And the same for the next event after five seconds as well. So now we've used a completely separate model to authorize on that channel using the order ID,
04:09
but slightly changing around the way that we define this. You could keep this channel for just global notifications for that user and this specifically for an orders page if you wanted to. Now, just before we go, we can do a little bit of tidying here
04:24
just to make our events a little slimmer. So if we head over to our events that we've created, let's start with dispatched. What we can actually do is get rid of passing the user through because from the order we already know the user ID.
04:39
So let's get rid of the user. And let's change this up to say order and user ID. So a lot more efficient. We're not passing in a model that we don't need.
04:49
If we want to broadcast on this channel, we can grab the user's ID. Let's do the same thing for order delivered as well. So let's say order and user ID. And let's go and get rid of the need to pass the user through here as well.
05:04
OK, so over in our web routes where we're dispatching this, we can obviously change this around to get rid of the user. And we should be good. OK, let's head back over, try this out.
05:18
So give both of these a refresh, rebroadcast this and just wait for the events to come through. And both of them are now coming through. Great.

Episode summary

In this episode, we're spicing things up by broadening our broadcasting logic. Instead of pushing notifications only to the global dashboard, we set up broadcasting to specific order pages too. Think of it like users waiting on a dedicated order status page—now they'll get immediate updates there as well as globally.

We start by creating a route and view for individual orders, so users can get live updates about specific orders. You'll see how we pass data between controllers and views, set up templates, and ensure each order page is ready to listen for relevant events.

Next, we get into the nitty-gritty of authorizing users to listen to private channels specifically tied to an order. We define a new channel, 'orders.{orderId}', and implement logic so only the owner of the order can listen to its updates. You’ll see how to fetch the order and compare its user ID to the currently authenticated user.

Then, we tweak our events to broadcast to this model-specific channel as well as the global one. We tidy up our event payloads for efficiency—removing unneeded data and relying on relationships already in the model.

Finally, we test everything out: trigger the events, and watch real-time updates flow both to the dashboard and the specific order page. It all comes together, and you’ll see this approach gives you clear, secure notifications whether you want global updates or just order-specific ones.

Overall, this episode is all about tweaking your broadcasting and authorization logic to target updates more precisely and make your Laravel real-time features even more useful.

Episode discussion

No comments, yet. Be the first!