Okay, take a good look at the screen and see if you can work out what the issue is here. Have you worked it out? Take your time. Line 48. Well, it looks okay, but note there's no middleware. Do you think we should have middleware in place? Absolutely we should. We should be checking, ensuring that the User is logged in before they are allowed to post a Comment, but as is, actually a guest could hit this route. Now wait a minute, didn't we already check from the browser's point of view in the last episode that a guest couldn't actually post a Comment? We did. An error was thrown. So what was that error? Well, if we take a look at the store method in our CommentController, the error comes from this line here, where we attempt to grab the User object from the request and then the ID property on that User object. The thing is, there is no User object because you're a guest. So

line here, where we attempt to grab the User object from the request and then the ID property on that User object. The thing is, there is no User object because you're a guest. So when we attempt to access the ID, php throws a runtime error. This has nothing to do with authentication and if this line was hard-coded, let's say we set the User ID to one, well anybody would be able to come in and post a comment. A security hole has been opened in our application and if we don't do something about it now, we risk people taking advantage of that down the line. This just goes to show that even if you write a good portion of tests, you must make sure you think about edge cases because even the best of us, myself included, will skip over those at times and when that happens, well that's where you start to trust too much in the process of TDD and you don't think about the consequences of your actions.

will skip over those at times and when that happens, well that's where you start to trust too much in the process of TDD and you don't think about the consequences of your actions. It's also a good time to remember that you should test more than the golden path. If we take a look at our test, we check we can store a Comment, we check that we redirected the correct page and then we check validation, but we've never checked that a guest cannot post a Comment, the non-golden path. So yes, think about those alternative routes that people might take into your application. What would a bad actor, a bad apple try to do to hack your application and test for those scenarios as well? Tell you what, why don't we write this test together to make sure that we have this base covered once and for all? We'll start with our it function and we'll say that it requires authentication. We can

we write this test together to make sure that we have this base covered once and for all? We'll start with our it function and we'll say that it requires authentication. We can open up our test enclosure after that and then inside here, well we want to make a post request without logging in, so I'll import the post function from the pest Laravel plugin. We'll post to the root of comment store and we obviously have to pass in a post to store the comment alongside, so there we go. I'm not going to pass a payload because we should never reach the point of validation, so the payload won't matter. In order to check that this works, well that's going to depend on the authentication middleware that you have in place. In our case, I want to place this root here inside this group that Jetstream ships with, which is going to check auth sanctum. It's also going to check the Jetstream auth

in place. In our case, I want to place this root here inside this group that Jetstream ships with, which is going to check auth sanctum. It's also going to check the Jetstream auth session. Now basically what that's going to do is redirect Inertia to the logging page if you are a guest and you hit a root that requires authentication. So in order to check that it requires authentication, what we're actually wanting to check for is a redirect to the login root. So if everything works correctly, then this test should pass, but as we can see, the test fails. This is a great time to stop and just talk about this workflow when fixing bugs in your applications. Don't be tempted to go and write the fix right away. Usually when a bug comes up, we can be under the hammer a little bit. We're a bit worried about timing, so we quickly patch it and push it out. But if at all possible, take the time

Usually when a bug comes up, we can be under the hammer a little bit. We're a bit worried about timing, so we quickly patch it and push it out. But if at all possible, take the time to write a failing test first that will prove that the bug is fixed. And by doing so, well, you can have confidence that this bug will never rear its head again in your application. So yes, we have a failing test here, and the fix is going to be to go into our web.php file, cut this line out, and we'll paste it inside this group that I talked about a little earlier. And now when we rerun our test, you can see that it passes. So all in all, this was quite a simple fix. In fact, if we'd done it in the first place, we would never have had this issue to worry about. But as application developers, we make mistakes. It's part of the job process. You will make mistakes no matter how experienced you are,

have had this issue to worry about. But as application developers, we make mistakes. It's part of the job process. You will make mistakes no matter how experienced you are, no matter how well you know the Laravel framework, no matter how much you test, because you will miss things. The important skill to develop is being able to write tests that prove that something went wrong, and then working to fix them in the most efficient manner possible. And thanks to this very simple test that checks that a route requires authentication, well, we've done exactly that. And we've plugged this hole in our app. In the next episode, why don't we take a look at being able to delete a Comment that you've posted in the past.

past.