Build Your Own PHP Framework

Sign in Get started

This episode is for members only

Sign up to access "Build Your Own PHP Framework" right now.

Already a member? Sign in to continue

Playing

43. How middleware works

Episodes

0%

Your progress

Total: 4h 45m
Played: 0m
Remaining: 4h 45m

Join or sign in to track your progress

01. Setting up

01. Introduction

02. Composer and PSR-4 Autoloading

03. Bootstrapping and structure

04. Error reporting with Ignition

02. Container

05. Using a container

06. Adding service providers

07. Autowiring with reflection

08. Refactoring to a singleton

03. Application config

09. Building the Config class

10. Reading and merging config files

11. Registering service providers through config

12. Using env files

04. Routing and controllers

13. Everything starts with requests

14. Adding routing

15. Responding in routes

16. Cleaning up responding

17. Defining routes in a separate file

18. Creating a controller

19. Using services inside controllers

05. Views

20. Installing Twig

21. Rendering a view

22. Debugging in Twig

23. Creating a base layout

24. Page titles in Twig

25. Creating a Twig config helper

06. Database

26. Setting up and querying the database

27. Working with models

28. Creating an example user profile page

07. Authentication

29. Setting up Sentinel

30. Creating the registration flow

31. Registering and authenticating a user

32. Showing authenticated state

34. Logging out

08. CSRF Protection

35. Protecting routes with CSRF

36. Adding tokens to forms

09. Flashing messages

37. Basic session flashing

38. Creating a Twig helper and flashing globally

10. Validation

39. Validating the login form

40. Manually adding validation errors

41. Validating the registration form

42. Custom validation rules

11. Middleware

43. How middleware works

44. Adding auth middleware and grouping routes

45. Persisting old form data

12. Exception handling

46. Creating an exception handler

47. Custom 404 (and other error) views

48. Rendering views for CSRF errors

13. Pagination

49. Paginating with Eloquent

50. Building a pagination view with Twig

14. Global helpers

51. Registering functions with PSR-4

52. Container resolution helper

53. View and config helpers

54. Route generator helper

Transcript

00:00

We've already seen an example of middleware in action, but let's go ahead and build our own middleware to figure out how this works.

00:06

And then in the next few episodes, we'll discuss what we can do with this middleware. The two main things that we're going to be doing is creating our middleware to protect routes. For example, we're going to protect the dashboard route if the user is not signed in, and we're going to redirect them over to the login page.

00:22

And we're also going to look at some middleware to keep old form data. So if we have any validation errors, we want to keep that data inside of the forms. Both of these things can be achieved by middleware. Okay, so we saw this example of middleware here, but like I said, we haven't built our own.

00:39

So let's go over to the HTTP directory, and let's create another directory in here called middleware. And let's just build our own example piece of middleware. So I'm going to go ahead and create out a class in here, just call it example middleware. And let's go ahead and start to fill in what we need to get this working.

00:57

So really, the first thing that we need to do is implement the middleware interface. So let's go ahead and pull that in from PSR HTTP server. Remember, we're using the PSR standards within our router as well. So our middleware needs to implement this.

01:12

And then we go ahead and create out a process method. Now, we fill this in automatically within here, but let's just take a look at what we have here and here. So the first thing that we have is the request, we've already seen this within our application. This allow us to extract data from the current request, for example, what the method that's being used,

01:32

the location that's being requested, and any data inside of the request. But then we have this handler being passed in. Okay, so if you are new to middleware, let's take a minute to talk about how this works. So when we go ahead and register our route,

01:49

let's say that we wanted to apply the middleware that we've just created to our dashboard controller. Well, we can go ahead and just say middleware, and then we can new up the middleware that we want to use. In our case, it's this example middleware. Now, middleware will be called before each of these routes is hit,

02:05

or we can do something within the middleware after. Now, what will happen is we can add multiple middlewares to any of the routes. Remember, we've already got a piece of middleware here, which is globally set for any route, and checks for that post or other HTTP methods to verify our cross-site request forgery token.

02:25

Well, this middleware will be called for any of these routes, including the dashboard, but we will also call this example middleware. So we call this a middleware stack. It will call the first piece of middleware,

02:37

and the middleware is responsible for calling the next piece of middleware. And then if there are no more middlewares in the stack, then we just go ahead and show the route. So think of it like an onion. It works from the outside in to what you're trying to access.

02:50

Okay, so we've got this example middleware added. We're not going to do anything with this just yet. Let's just go over to our dashboard and hit enter. Okay, so we have an error here because we need to return a response from our middleware,

03:05

and we need to call the next piece of middleware. We just spoke about that, but at the moment, we're not doing anything in here. Okay, so to very basically just handle the next piece of middleware or the next request to that route, we're going to use that handler.

03:19

So we need to return this. So let's return that handler, and let's handle this passing through the request. Now, the reason that we pass the request through is because the next piece of middleware needs access to the request. We might have modified the request, added something to it, and this will ensure that it gets passed to the next piece.

03:38

Okay, now that we've done that, we give this a refresh. You can see that we just land on our dashboard. Nothing else is happening because we're not doing anything inside of that middleware. Let's go ahead and just var dump something at the top of this middleware.

03:51

So I'm just going to say called, and let's go over and just give this a refresh. Okay, so we get an error here because we're trying to emit a response, but you can actually see that it's called when we sort of refresh and just flash this. So although we're getting this error just because we are outputting content within PHP and the headers have already been sent by this,

04:11

it doesn't really matter. We can see this in action. Now, there are two different ways that you can call middleware. This is the before style.

04:18

So this var dump is called before we hit a request to our application. What you can also do is change this up so you can invoke middleware after your application root has been hit. Now, to do this, you're going to go ahead and create our response in here. Let's just get rid of this handler so we can see what we're doing.

04:37

You're going to go ahead and handle the next piece of middleware like we just did down there, passing the request in. Then you're going to do something in the middle, and then you're going to return the response. So this is an after piece of middleware because we are grabbing the next callable thing, and then we're doing something. So this happens afterwards, and what we saw before was doing something before and then returning the response.

05:02

So again, if we just var dump something out in here called after, let's go over and give our page a refresh, and this is actually happening after this root gets hit. Although we get this error, it doesn't really matter. Just keep these in your notes so if you want to do something after a request has been hit, use this method.

05:21

Otherwise, we're just going to go ahead and return the handler and do something before. Now, the majority of the time, you'll be writing middleware that does something before the request. For example, in the next episode, we are going to be covering how to create middleware, which will prevent a user from accessing the dashboard if they're not signed in.

Episode summary

In this episode, we dig into how middleware works by walking through building our very own middleware from scratch. We kick things off by creating a new middleware class and making sure it implements the correct interface (using PSR standards). Then, we go step-by-step through how the middleware actually plugs into our application and the overall request/response cycle.

We also talk a lot about the middleware "stack" – basically, how multiple middleware can be layered together, each one having a shot at the request before it reaches your route. Think of it like layers of an onion: each middleware wraps around the next, doing its job on both the way in and the way out.

To make things practical, we demonstrate how to set up "before" middleware (code that runs before your main controller does) as well as "after" middleware (code that runs after the controller has done its thing, before the response goes back out).

We finish up with some quick experiments to make sure our middleware is firing as expected and talk about common use-cases, like route protection and persisting form data after validation errors. By the end, you'll have a good sense of how to write and stack middleware, setting you up for the more specific examples coming up in the next episodes!

Episode discussion

No comments, yet. Be the first!