CSRF Field Requirement0:00
Next up, let's review some updates to request validation, which is really nice. So here I have a standard form to create a post to the obligatory Post. And if we take a look at that, post/create, here's what I have here. Just a simple form, you've seen this a million times, right? Now the very first thing I want you to see is that it's going to POST to a typical RESTful endpoint. However, notice that I haven't added the CSRF field. Well, this is one change. So if I just try it out, even with some gibberish here, I'm going to get this new error page.
Setting Up Resource Route0:52
Otherwise, it's somebody doing something malicious. So just know, if you ever come across this and you're not sure what it means, it's always related to the CSRF field. So just add it on. And you won't see that. Okay, next, let's take a look at my routes/web.php file. I'm setting up just a simple route resource for posts, just to keep it quick. And you'll see if I come to the store method, that's empty. Okay, so generally what you do in these situations is you validate the post, and then you create it, right?
Traditional Request Validation1:18
Okay, so generally what you do in these situations is you validate the Post, and then you create it, right? So in the past, you would do something probably along the lines of this. You'd say validate the request, which you would either inject here, or you could just use the request helper function. And you would say something like title is required, and the body is as well. Okay, so as you know, if there's any validation errors in the process, Laravel will automatically redirect back and pass through an errors variable. So you can then check for that in your view and display them, which I haven't bothered setting up here.
So you can then check for that in your view and display them, which I haven't bothered setting up here. But yeah, nonetheless, if we tried to do this and we run it, Laravel just automatically redirects back, which is great. Otherwise, as usual, you would say post create. And then once again, you would say something like request only title and the body. So you've surely seen me do things like this many, many times over. Now, in this case, we would get a mass assignment exception unless you set the fillable fields. I'm just going to cheat and say forceCreate for the time being.
unless you set the fillable fields. I'm just going to cheat and say forceCreate for the time being, and then we'll just return done. Okay, so sure enough, if we try this out and run it... Uh-oh, we forgot to import the Post class. But once again, this is a nice illustration of the whoops integration that we talked about in the last episode. All right, run it again, and we're all set. So that means if I boot up php artisan tinker and I fetch all of my posts, sure enough, it's there.
Request validate() in 5.52:39
So that means if I boot up php artisan tinker and I fetch all of my posts, sure enough, it's there. Okay, so what's new in Laravel 5.5? Well, we can now call validate directly on request. And if you think about it, or at least in my mind, this makes good sense. The ability to say request->validate yourself, I think that makes good sense. It's a nice object-oriented approach. So rather than calling validate on the controller and then passing in request, we'll just tell request to validate itself. And now we can get rid of that entirely.
Returning Validated Data3:07
we'll just tell request or request to validate itself. And now we can get rid of that entirely. So if we save that and give this another shot, we're still going to get the exact same thing as we had before. There you go. But yeah, I think that's a more object-centric approach to going about this. Okay, but we're not done yet. So as it turns out, in Laravel 5.5, when you call validate, it's going to return the validated data, which means we could say validatedData, just to be very clear here.
it's going to return the validatedData, which means we could say validatedData, just to be very clear here. And then I'm going to dump this so you can check it out. Okay, so let's come back and give it another shot. So if we run it and pass everything through, sure enough, we do get title and body. But that's not the main thing I want to show you. What if you had a different field that was passed through, even something maliciously by the user? For now, we'll just say input type is hidden. We'll say name is thing and value is foobar.
For now, we'll just say input type is hidden. We'll say name is thing and value is foobar. Okay, so now if we come back and give this another shot, what you're going to see is that the thing request data is nowhere to be found. Now, if we were to come back, though, to PostController, and I were to dd(request->all()) and run it again, you'll see that it is present, right? So this is a very key thing to understand. When you're calling request->validate(), what gets returned is not all of the request data. It is the equivalent of request->only() what you have specified here.
When you're calling request()->validate(), what gets returned is not all of the request data. It is the equivalent of request()->only() what you have specified here. So you can think of it as request()->only('title', 'body') is what's going to get returned. And anything else that's not included here will be ignored. So that's something you need to factor into your refactor if you adopt this. If you were assuming that you would have other data that wasn't present in your validation, that's something you need to be aware of. But nonetheless, I think you're going to find that this is incredibly useful. Because think about it. Now, you no longer have to do this thing that is so common in your controllers,
Persisting With Validated Data5:04
Because think about it. Now, you no longer have to do this thing that is so common in your controllers, where you call validate, you give the keys. And then when you're ready to persist the data, you call request again, and you give those exact same keys. So you're doubling up all of the work. Now, I can just say forceCreate with the validated data, or that's a terrible name. Let's just say post. Okay, so we're going to come back, give this another shot.
Let's just say post. Okay, so we're going to come back, give this another shot. My post, blah, blah, post it. And now, once again, we get the exact same thing as we had before. But yeah, I think this is a significantly cleaner way to do it.
