Next up, let's talk about security, and specifically, how we can be a bit more thoughtful about what data we expose for serialization. Okay, so have a look here. We currently have four routes that handle the User in our system. So this page corresponds to this section of our demo app. Okay, so if we take a look at this first index action, again, that corresponds to this exact view. We can see we are grabbing our users, but we're not sending and serializing everything. We only care about the id and the name. So we use this through method to transform the underlying collection in the paginator.

We only care about the ID and the name. So we use this through method to transform the underlying collection in the paginator. So if we take a look at this, let me open up Vue DevTools, yeah, right here. If we go into our users, I'm not going to see all the data from that table. I only see the ID and the name, and then this extra can property that I added. Okay, so this is working great. No problem at all. When you're building an application, this is a good way to go. But what about when you're instead migrating an existing application, either to Inertia or to an SPA entirely?

But what about when you're instead migrating an existing application, either to Inertia or to an SPA entirely? In fact, this is something I had to deal with for Lerikas. It can be a bit of a tricky thing because you're dealing with a site that potentially has hundreds of endpoints. And so what can happen if you're not careful is you might end up with a particular action that is not being transformed correctly. And it's perfectly clear why this might happen. Before you had an SPA, you were a server-side application, in which case passing a User model to, for example, a Blade view is no problem at all.

Before you had an SPA, you were a server-side application, in which case passing a User model to, for example, a Blade view is no problem at all. But the rules are a little different, of course, with an SPA. So let's have a look here. This is the show view. So if I click on any of these, it's just a simple page that shows their name and email. If we now open up DevTools again, take a look at the show view, and we can see that potentially on certain pages, the users in our system can access data that they shouldn't have access to and potentially dangerous data that they shouldn't have access to. So this is one of the things that concerned me when I was migrating over to an SPA.

to and potentially dangerous data that they shouldn't have access to. So this is one of the things that concerned me when I was migrating over to an SPA. There are dozens and dozens and hundreds of pages. And if you make one mistake, you expose really sensitive information to the end user. Okay, so here are some ideas that you might consider. And again, I'm targeting somebody migrating an existing application. Okay, so if we go to my User model, of course, one option is to do something like this. Let's override the toArray method. And for now, I'm just going to return an empty array. So we're effectively disabling serialization entirely.

And for now, I'm just going to return an empty array. So we're effectively disabling serialization entirely. Take a look at this now. If I give it a refresh, I don't see any of my data. And notice that for user, yeah, it's an empty array. So this is one way that we could deal with this. We disable it entirely to protect ourselves. And yet in situations like this, I would rather potentially have a broken page than risk sensitive data being improperly exposed. Alright, so that is one option and it becomes immediately visible that there is a problem.

data being improperly exposed. Alright, so that is one option and it becomes immediately visible that there is a problem. So we could go back to our UsersController and fix this, track it down, and we can see, okay, I only want to grab the id, the name, and the email, and maybe create it out. Okay, now that we're being explicit, we get that information. And again, let's have a look. And yeah, this is exactly what I want. Alright, it's an option. Let's go ahead and bring it back to what I had before though. Another option you might consider, let's get rid of this, if I scroll up, is we could append

Let's go ahead and bring it back to what I had before though. Another option you might consider, let's get rid of this, if I scroll up, is we could append to the hidden property. So the hidden property on your Eloquent model, as it says on the 10, specifies attributes that should be hidden when serialized. So maybe, let's give it a refresh, maybe it turns out that only a couple attributes or columns on your User model are especially sensitive. Maybe in this case, we'll say strikeToken. Okay, I could add that here. And now, unless I explicitly include it, it will never show up for the end user.

Okay, I could add that here. And now, unless I explicitly include it, it will never show up for the end user. So we give that a refresh, and I expect it to not be there, and it's not. Okay, so that's an option as well. If you're building a smaller application where most of the time, the data you pass to the client almost exactly mimics the database structure, yeah, that might be an option you consider. Now, here's another option you might consider. We could flip this. So this will effectively be more like the toArray method we demonstrated earlier.

We could flip this. So this will effectively be more like the toArray method we demonstrated earlier. If I switch it over to visible, think of this sort of like the allow list. Only the attributes in this array may be included for serialization. So I could say name, email, and now if I come back and give it a refresh, you'll see we are being explicit about what attributes may be passed to the client. So that's an option as well. Or again, if you just want to disable it entirely, like toArray, I could just make this an empty array, and now nothing will be serialized. Give it a refresh, and you'll see it should be empty again.

can see, oh, I need to be careful here. I'm passing a fully serialized model to my Inertia view, and I don't want that. So let's bring this back. I think we needed the name, the email, and created_at. And then I'll take care of it. All right, very cool. So in the next episode, let's move on to API resources.