Check out a free preview of the full Building APIs with C# and ASP.NET Core course
The "Middleware & Filters" Lesson is part of the full, Building APIs with C# and ASP.NET Core course featured in this preview video. Here's what you'd learn in this lesson:
Spencer introduces middleware and filters. Middleware intercept and handle HTTP requests and responses in ASP.NET Core. Filters can modify the behavior of requests in ASP.NET Core, but only after the request has been routed to a controller method. The advantage of filters is they engage after the route has been matched and model binding has occurred.
Transcript from the "Middleware & Filters" Lesson
[00:00:00]
>> Spencer Schneidenbach: So I wanna talk about middleware and filters as they relate to controllers. So I wanna give a brief review on middleware. This image is from the ASP.NET Core docs, and pretty well describes what I said earlier, which is that middleware kinda flows like a pipeline, and middleware is simply different sections of that pipeline.
[00:00:19]
And as water, or in this case, our request flows through that pipe, our middleware is able to do things to it. It can actually change the nature of the request, but it can also just decide whether or not it can handle it, or move it on to the next piece of middleware.
[00:00:33]
That's what this illustrates, right? We have our piece of middleware, it has some logic, and it's gonna call the next piece of middleware if it realizes or if it figures out that it can't itself handle the request. Or it's going to modify parts of that request to add things to it for other middleware in the pipe.
[00:00:51]
And then you'll remember that during the intro to this, as we were talking about middleware inside of ASP.NET Core, we were talking about how we could block pretty much all requests for being handled by simply adding this use. Which is just a way of saying, add this middleware that's executed from this delegate or function.
[00:01:13]
We can use app.Use, and as long as we don't call the next piece of middleware in the pipeline, we're gonna go ahead and stop processing. So one of the things that you can do as an experiment just for fun is open this solution up and try copying and pasting this around and see how it modifies or changes different aspects of your program.
[00:01:36]
Middleware order is extremely important, and especially when we're talking about authorization and things of that nature. The order of middleware becomes supremely important, especially as your application grows in complexity.
>> Spencer Schneidenbach: So this is the typical middleware used in ASP.NET Core web app that might serve more than just an API, it might serve static files.
[00:02:04]
It actually would serve static files, because it would serve your JavaScript and your CSS. So it has a middleware for that to say, if there's a static file that exists at that path, then return that. Otherwise, move down to use routing, which is a way of establishing routing rules inside of ASP.Net Core.
[00:02:23]
Then, of course, use authentication and then authorization. One must come before the other. You've got to authenticate. We have to know who you are before we can determine that you can do the thing that you're asking to do. And then map razor pages, which is just a flavor of web framework that ASP.Net Core provides, and then go down to controllers if we can't go to a razor page.
[00:02:48]
I wanna touch on, do I actually ever write my own middleware? And the answer is that I do. It's not super often, because at that point, I'm pretty well aware. It's not like I'm writing middleware every week. It's like, I gotta handle this different kind of request. Most of the time, if I'm adding endpoints, I'm adding them to controllers or something along those lines.
[00:03:06]
I'm adding them to controllers, because ASP.NET Core already knows how to handle those things. But I have done it and here's a really brief example of when I might have to do it. For example, if I have a multi-tenant SaaS app and I need to establish what tenant that we are working on, then I might read, if we say, type in, if our application was something like the Microsoft example of Contoso.
[00:03:35]
And we decided that we would discriminate on whether or not this was, say, the subdomain of Frontend Masters. That that was the tenant that frontendmasters.contoso.com was a specific tenant and pointed to a specific piece of our software. So that way, we contained all their data to that one place.
[00:03:59]
We might read that Frontend Masters and then look up that tenants ID based on the value of that subdomain. So stuff like this where you're kind of building in or enhancing your application and adding in specific behaviors that are custom to you. How do I identify this tenant so that downstream other middleware can use that tenant ID?
[00:04:19]
This is where you might do that. The purposes of this course, and for the purposes of this discussion, it's important to know what middleware is and what it's used for. But day-to-day, you don't really have to think about it that much, because most of the time you're setting it up.
[00:04:33]
Once you're modifying it so often as your business requirements change, and then you're just letting ASP.NET Core do its thing. But I do want to talk about filters. And filters are a way to modify behavior requests, but only after the request has actually been routed to something that ASP.NET Core MVC does.
[00:04:52]
So, for example, a controller method. At the point that it's actually going through and executing that controller method, it's actually already done a bunch of stuff under the hood. It's done some model binding, so it knows that the body of the request goes into this particular object that we've specified.
[00:05:07]
So at that point, we can use filters to even change that behavior further. You can think of them as micro middleware, but they're very specialized to just handle functions within ASP.NET Core. And there's a bunch of different built-in types of middleware, there's authorization filters, for example, to say that, are you authorized to use this particular resource?
[00:05:27]
Is this user have this permission, or is this user part of this role? You could enable cores for a specific action or controller. And that is to determine whether or not to establish cross-domain boundary rules so that a browser can figure out, can I actually access this resource, cuz it's outside of the webpage that we're executing in?
[00:05:52]
Should we cache this response? And for how long should we require HTTPS? Or maybe we have an AntiForgeryToken, because we wanna prevent some kind of attack. So do we wanna validate our ForgeryToken before we get to actually executing this method? So there's several different kinds. The one that we will touch on is the authorize filter, which is very important.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops