Chapter 22: Creating custom MVC and Razor Page filters

Introduction

This chapter introduction previews creating custom MVC and Razor Pages filters to remove duplicate request logic, short-circuit requests, and use dependency injection in attribute-based filters.

• Custom filter purposes: Describe how custom MVC and Razor Pages filters can be created and used to reduce duplicate code in action methods and application request handling.
  Why it matters: Filters let you move shared cross-cutting logic out of individual actions and pages.
• Filter type selection: State that section 22.1 covers the available custom filter types, where they fit in the MVC pipeline, their intended uses, example implementations, and built-in options.
  Why it matters: Choosing the appropriate filter type depends on when its logic must run in the MVC pipeline.
• Filter pipeline short-circuiting: Explain that a filter can short-circuit a request by generating a response and stopping further progression through the filter pipeline, and distinguish this from middleware short-circuiting by noting that MVC filter behavior has subtle, filter-specific differences.
  Why it matters: Short-circuiting determines whether later filters and an action or page handler get to run.
• Dependency injection in attributes: Explain why ordinary filter attributes cannot easily use dependency injection because of C# attribute limitations, and describe using ServiceFilterAttribute or TypeFilterAttribute base classes to enable DI in filters.
  Why it matters: These attribute-based approaches let filters use application services without giving up attribute-based application.

Key terms: custom filters, MVC filters, Razor Pages filters, action methods, filter types, MVC pipeline, built-in options, short-circuiting, filter pipeline, middleware

22.1 Creating custom filters for your application

This section introduces refactoring a recipe web API controller by moving duplicated cross-cutting concerns into custom MVC filters.

• Filter-based controller refactoring: Explain that the recipe controller is refactored by moving code unrelated to an action’s main intent into custom filters, leaving the action methods simpler and easier to read.
  Why it matters: Filters let actions emphasize the business operation they perform instead of repeated infrastructure concerns.
• Duplicated controller concerns: Describe the duplicated concerns in the starting recipe controller: checking whether a Recipe entity exists and formatting exceptions, alongside code that obscures each action’s intent.
  Why it matters: Recognizing repeated cross-cutting concerns helps you identify good candidates for filters.
• Synchronous filter implementation: State that the custom filters created in this section use synchronous filter interfaces, while creating asynchronous counterparts is left as an exercise.
  Why it matters: This tells you which form of the filter interfaces the examples implement.

Key terms: custom filters, cross-cutting code, action methods, recipe controller, Recipe entity, RecipeDetailViewModel, exceptions, duplication, sync filter interfaces, async counterparts

22.1.1 Authorization filters: Protecting your APIs

This section introduces MVC authorization filters and shows how the built-in [Authorize] attribute protects actions, controllers, Razor Pages, or an entire application.

• Authentication and authorization distinction: Distinguish authentication from authorization: authentication determines who made a request, whereas authorization determines what that user is permitted to access.
  Why it matters: Separating identity from permissions makes it easier to reason about how an endpoint is secured.
• Authorization filter pipeline role: Explain that authorization filters run before every other MVC filter and control access by short-circuiting the pipeline immediately when a request fails the required authorization conditions.
  Why it matters: Running first prevents an unauthorized request from reaching action logic or later filters.
• Authorize attribute protection scopes: Describe how the built-in AuthorizeFilter is added with [Authorize], and state that its simplest use requires an authenticated user; an unauthenticated request is short-circuited with a 401 Unauthorized response. Explain that the attribute can protect one action, all actions on a controller, all handlers on a Razor Page, or every application endpoint when applied globally.
  Why it matters: The [Authorize] attribute provides a direct, built-in way to apply consistent access protection at the scope an application needs.
• Built-in authorization framework: Justify using ASP.NET Core's built-in authorization framework and configurable custom policies instead of writing custom IAuthorizationFilter or IAsyncAuthorizationFilter implementations for normal authorization needs.
  Why it matters: Using the framework avoids unnecessary custom filters while still allowing fine-grained control over access.

Key terms: authentication, authorization, authorization filters, MVC filter pipeline, short-circuiting, AuthorizeFilter, [Authorize], authenticated user, 401 Unauthorized, controller

22.1.2 Resource filters: Short-circuiting your action methods

This section shows how resource filters run around MVC processing to enforce early cross-cutting rules and short-circuit requests before an action executes.

• Resource filter timing: Explain that resource filters are general-purpose MVC filters that run early, before model binding, and also have an execution point after the result executes. Describe why their early position makes them suitable for quickly stopping a request before action or page-handler logic runs.
  Why it matters: Resource filters let you avoid unnecessary model binding and endpoint logic when an early request-level rule fails.
• Feature-enabled resource filter: Describe how FeatureEnabledAttribute moves an API feature-toggle check out of Get and Edit action methods into a reusable resource-filter attribute. State that the attribute can be applied to a controller, action method, or Razor Page and exposes IsEnabled as a property.
  Why it matters: Putting a feature check in one reusable filter removes duplicated cross-cutting logic from endpoint methods.
• Result-based pipeline short-circuiting: Explain that a resource filter short-circuits by assigning an IActionResult to the execution context's Result property. State that MVC executes that result for the response while bypassing remaining filters and skipping the selected action method or page handler; in the feature example, a disabled feature returns BadRequestResult, a 400 response.
  Why it matters: Setting Result gives a filter a clear way to reject a request without letting the normal endpoint-processing path continue.
• Built-in resource filters: State the purposes of ConsumesAttribute and SkipStatusCodePagesAttribute. Describe that ConsumesAttribute can reject an unsupported request content format with 415 Unsupported Media Type, while SkipStatusCodePagesAttribute prevents StatusCodePagesMiddleware from modifying a response, such as API error responses in a mixed API and Razor Pages app.
  Why it matters: Built-in resource filters can solve content-type and error-response concerns without writing a custom filter.

Key terms: resource filters, model binding, MVC filter pipeline, FeatureEnabledAttribute, IsEnabled, feature toggle, cross-cutting logic, resource filter attribute, context.Result, IActionResult

22.1.3 Action filters: Customizing model binding and action results

This section shows how MVC action filters use post-binding request data and pre/post-action hooks to centralize validation, entity checks, response changes, and controller-wide logic.

• Action filter execution points: Explain when action filters run and what they can access or change: they run after model binding before an action, and again after it, so they can inspect bound arguments, short-circuit execution, replace an IActionResult, or handle an action exception.
  Why it matters: Their position in the MVC pipeline makes action filters a useful place to remove repeated action-method logic.
• Model-state validation filter: Describe how a ValidateModelAttribute-style action filter checks context.ModelState after binding and sets context.Result to BadRequestResult when the binding model is invalid, avoiding repeated validation checks in API actions. State that [ApiController] normally provides this behavior automatically, including Problem Details responses.
  Why it matters: Centralizing invalid-model handling keeps web API action methods focused on successful request behavior.
• Recipe existence action check: Describe how EnsureRecipeExistsAttribute obtains the already-bound id from context.ActionArguments, checks it with RecipeService, and sets context.Result to NotFoundResult when no Recipe exists. Explain that resolving RecipeService through HttpContext.RequestServices is service location and is presented as an antipattern.
  Why it matters: This pattern demonstrates how action filters can extract repeated resource-existence checks from multiple actions.
• Action-filter short-circuit scope: Explain that assigning context.Result in an action filter short-circuits the action stage: it bypasses the action method and later action filters, but other pipeline stages continue as though the action had executed.
  Why it matters: Knowing exactly what is skipped prevents incorrect assumptions about which filters and result processing still run.
• Controller-based action filtering: Describe the controller-specific alternative of overriding OnActionExecuting and OnActionExecuted on ControllerBase when logic applies to every action in one controller. State that the pre-action override runs before all other action filters and the post-action override runs after them, but its relative ordering cannot be controlled.
  Why it matters: This gives a compact option for controller-wide behavior while clarifying why explicit filter attributes are often preferable.

Key terms: action filters, model binding, IActionResult, action method, ActionFilterAttribute, ValidateModelAttribute, ModelState, context.Result, BadRequestResult, [ApiController]

22.1.4 Exception filters: Custom exception handling for your action methods

This section explains when MVC exception filters are preferable to global exception-handling middleware, what exceptions they can catch, and how they enable API-specific error responses.

• MVC-specific exception handling: Explain why an exception filter is useful alongside exception-handling middleware when error behavior must be specific to MVC or to selected routes. Describe how the filter can access MVC context, including the executing action or Razor Page and its action parameters, to log additional error details.
  Why it matters: Exception filters let an application make informed, route-specific error-handling decisions instead of treating every failed request identically.
• API-specific exception responses: Describe how an exception filter can catch an API controller exception and generate an appropriate response body for a JSON client, preventing the global exception handler from returning an HTML error page to that client. State that the exception handler middleware allows the modified API response through because it only intercepts errors without a body.
  Why it matters: An API client expecting JSON can fail if an unhandled API exception is turned into an HTML error page.
• Exception filter coverage limits: Distinguish the stages whose exceptions exception filters catch from stages they do not catch. State that they handle failures during model binding or validation, action or page-handler execution, and action or page-filter execution, but not failures in other filter types or while executing an IActionResult such as rendering a Razor view.
  Why it matters: Knowing the filter's boundary prevents relying on it to handle exceptions that will instead escape to other error-handling mechanisms.
• Sensitive argument logging: State the risk of logging action-method arguments from an exception filter: those arguments can include sensitive values such as passwords or credit-card details and must not be stored in logs.
  Why it matters: Helpful diagnostic context becomes a security problem if logs expose users' secrets or payment data.

Key terms: exception filters, exception-handling middleware, MVC framework, cross-cutting concerns, action parameters, exception filter, web API controller, Razor Pages, exception handler middleware, JSON

22.1.5 Result filters: Customizing action results before they execute

This section explains how MVC result filters customize IActionResult execution, including output formatting and last-minute response changes.

• Result filter execution stage: Explain when result filters run in the MVC pipeline: immediately after action filters and before and after an IActionResult executes. Distinguish normal result-filter execution from short-circuiting cases that bypass this stage.
  Why it matters: Knowing where result filters run tells you whether they can customize a result before ASP.NET Core generates the response.
• Result output customization: Describe how result filters customize the execution of an IActionResult, especially by controlling response output formatting. State how ProducesAttribute and FormatFilterAttribute select a response format.
  Why it matters: Result filters provide a focused place to alter how an action result becomes an HTTP response.
• Custom result-filter adjustments: Describe how a ResultFilterAttribute can inspect context.Result before execution and make a response adjustment, such as adding a Last-Modified header when the result is an OkObjectResult containing a RecipeDetailViewModel. Explain that OnResultExecuted can inspect execution exceptions but generally cannot modify a response that may already be streaming.
  Why it matters: This shows the practical boundary between changes that must happen before result execution and observations possible afterward.
• Appropriate filter usage: Justify using filters chiefly for repetitive HTTP-related or common cross-cutting controller code, rather than treating them as the default design choice. Describe private controller methods or domain code as preferable alternatives when they fit.
  Why it matters: Using filters selectively avoids moving narrowly specific or domain behavior into an unnecessarily complex pipeline abstraction.

Key terms: result filters, IActionResult, action filters, context.Result, short-circuiting, ProducesAttribute, FormatFilterAttribute, output formatters, Accept header, format

22.1.6 Page filters: Customizing model binding for Razor Pages

This section explains how Razor Page page filters parallel action filters, how they access bound values, and when their use is worthwhile.

• Page filter scope and role: Distinguish page filters from action filters by stating that page filters apply to Razor Pages but not controllers or actions, while action filters apply to controllers and actions but not Razor Pages. Explain that the two filter types fulfill similar roles, including a Razor Page caching filter equivalent to the action-filter caching behavior.
  Why it matters: Choosing the correct filter type ensures cross-cutting logic runs for the endpoints it is intended to affect.
• Page handler execution hook: Describe that an IPageFilter must implement three methods, but that page filters commonly use OnPageHandlerExecuting to run after model binding and validation and before the page handler executes. Explain that running immediately after handler selection and before model validation is comparatively uncommon.
  Why it matters: Knowing this timing lets you put page-level checks or changes at the point where validated bound values are available before handler code runs.
• Razor Page bound-value access: Explain that a page filter can read model-bound handler arguments from context.HandlerArguments, unlike an action filter, which uses context.ActionArguments. Describe the alternative of casting HandlerInstance to the appropriate PageModel type and reading a public property bound with [BindProperty], avoiding magic strings.
  Why it matters: These access options let a page filter inspect the values it needs while fitting the way Razor Pages commonly binds request data.
• Page filter design tradeoff: Justify using a page filter primarily for a common requirement shared across Razor Pages, rather than as a first choice for a single bespoke page. Explain that the extra indirection of filters often outweighs their benefit for individual Razor Pages, where PageModel can directly override filter methods for a single page.
  Why it matters: This guidance helps keep individual Razor Pages direct and understandable while reserving filters for genuinely reusable behavior.

Key terms: page filters, action filters, IPageFilter, PageResponseCacheFilter, ResponseCacheFilter, OnPageHandlerExecuting, model binding, model validation, page handler, HandlerArguments

22.2 Understanding pipeline short-circuiting

This section explains how MVC and Razor Pages filter short-circuiting changes pipeline execution and when result filters can still run.

• Filter short-circuit behavior: Explain that authorization, resource, action, page, and result filters can short-circuit by setting context.Result to an IActionResult, and that the amount of pipeline bypassed depends on the filter stage. Distinguish action and page filter short-circuits, which bypass later filters in that stage and the handler/action execution but still allow result filters and result execution to run.
  Why it matters: Choosing the filter stage determines which application work is skipped and which response-processing filters still execute.
• Same-stage filter execution: Describe what happens when a filter short-circuits in a stage containing multiple filters: later filters in that stage do not run, while earlier filters that already ran their Executing method receive their Executed call. Explain that an earlier resource filter sees context.Cancelled set to true when a resource filter in that stage short-circuited.
  Why it matters: This behavior lets wrapping filters recognize that inner pipeline work was cancelled rather than completed normally.
• Always-run result filters: Explain that ordinary result filters do not run for an IActionResult supplied by an authorization, resource, or exception filter that short-circuits the pipeline. Describe using IAlwaysRunResultFilter or IAsyncAlwaysRunResultFilter when a result transformation must also apply to those short-circuit results.
  Why it matters: Always-run result filters ensure essential response transformations are applied even when an earlier filter generates the response.

Key terms: short-circuiting, context.Result, IActionResult, action filters, page filters, result filters, resource filters, Executing, Executed, context.Cancelled

22.3 Using dependency injection with filter attributes

This section shows how to use dependency injection in MVC and Razor Pages filters by separating filter behavior from attributes and choosing TypeFilterAttribute or ServiceFilterAttribute.

• Attribute filter DI limitation: Explain why a filter implemented directly as a C# attribute cannot receive normal DI services through its constructor. State that attribute constructor arguments are limited to constant values and attribute instances are singletons for the application's lifetime.
  Why it matters: This limitation explains why filters that need scoped or transient services require a different design.
• Filter and attribute separation: Describe the two-class pattern for a DI-enabled filter: a filter class contains the behavior and declares services such as RecipeService as constructor dependencies, while a separate attribute determines where the filter is applied. Explain that the attribute can act as an IFilterFactory that creates the actual filter at request time.
  Why it matters: This pattern keeps actions conveniently decorated with attributes while letting the filter use proper constructor injection.
• TypeFilterAttribute behavior: Describe how TypeFilterAttribute supports the split pattern: an attribute derived from it supplies the type of the filter to create, and the framework creates a new filter instance while obtaining that filter's dependencies from DI. State that the filter itself does not need to be explicitly registered in the DI container for this approach.
  Why it matters: TypeFilterAttribute provides a convenient way to retain attribute-based filter usage without registering the filter itself as a service.
• ServiceFilterAttribute behavior: Distinguish ServiceFilterAttribute from TypeFilterAttribute. Explain that ServiceFilterAttribute resolves the filter itself from the DI container, so the filter must be explicitly registered and its DI lifetime controls its creation and dependency graph.
  Why it matters: Knowing this difference lets you choose whether the framework constructs a filter by type or DI supplies a registered filter service.
• Direct attribute simplicity: Justify implementing a filter directly as an attribute when it has no dependency-injection requirement, rather than adding an unnecessary filter-factory design.
  Why it matters: Using the simpler design when possible avoids extra classes and registration without losing needed functionality.

Key terms: attributes, dependency injection, singleton, transient, scoped, EnsureRecipeExistsFilter, EnsureRecipeExistsAttribute, IFilterFactory, CreateInstance(), RecipeService

22.4 Summary

This summary recaps the MVC and Razor Pages filter types, their execution roles and short-circuiting behavior, and how to use dependency injection in custom filter attributes.