What are filters in ASP.NET Core (authorization, resource, action, exception, result), in which order do they run, and how are they different from middleware?

Say it out loud, then check

Every filter, in order

The real output of a test app with one filter of each kind logging a line, for a normal call and then for an action that throws.

The story

1. Before

   BMW FS's contracts API has about forty actions that change a contract: approve, fund, change the payment date. (An action is one method of a controller class that answers one kind of request. A controller is a class that groups the actions for one area, like contracts. MVC is the part of ASP.NET Core that sends each request to the right action: the MVC card.) Every change must leave an audit record, a line saying who did what and when, which auditors check. In the first version every action started with the same few lines that wrote that record, copied by hand.

   Approve()audit lines + work

   Fund()audit lines + work

   Move datework only

   1/4Before: each action writes its own audit record, with the same lines copied in.A new action was added without the copy. Its changes left no audit record.Fix: one filter, registered once. MVC runs it around every action.Every action, old or new, now gets the audit record. Nobody has to remember.

   BackPlayNext
2. Why it had to change

   Code that every action needs, but that isn't the action's own job, is called cross-cutting: auditing, timing, turning errors into a standard response. Copied into each action, it gets forgotten or changed in one place and not the others.

3. How it works now

   A filter is a class that MVC calls at a fixed point while it handles a request for a controller action (a public method that answers a request). You write it once and register it for every action, for one controller, or for one action. There are five kinds, and each runs at its own point. Middleware is the similar idea one level out: code that every HTTP request passes through before MVC even starts (the pipeline, the middleware card). The main diagram follows one request through all of them.

4. What we gained

   The audit lines live in one class, every action is covered, and the actions only do their own work. The rest of the card shows where each kind of filter runs and when to pick a filter over middleware.

In the lending API

The audit filter: written once, run around every action; the diagram above shows where.

Only the key lines are shown; Deep walks the whole file.

The code, file by file

The BMW FS contracts API: start-up, a controller, and the audit filter. Tap Next to walk one request.

What they ask next

The follow-ups interviews really ask. Answer out loud, then tap to check.

• ReportedWhat is the difference between middleware and filters?

  Middleware is part of the ASP.NET Core pipeline: it runs for every request and sees the HTTP request and response; after routing it can see which endpoint was chosen, but not the arguments or the result. Filters are part of MVC: they run only when a controller action handles the request, and they know which action, its arguments, the model state (the result of checking the bound parameters) and the result. Use middleware for things every request needs (HTTPS, CORS, authentication, global error handling, request logging), filters for things that depend on the action (auditing changes, mapping a domain exception, validation rules for some actions).

  Middleware: every request
    UseExceptionHandler
    UseAuthentication
    UseAuthorization
    MVC (only for controllers):
    authorization filters
    resource filters
    model binding
    action filters → action
    exception filters (on error)
    result filters → JSON

  Next questions, in Deep →Colan Infotech: middleware vs filters
• ReportedWhat are the filter types, and in which order do they run?

  Authorization, resource, action, exception, result. Authorization first; resource filters wrap model binding and everything after; action filters wrap the action; exception filters only when controller creation, model binding, an action filter or the action throws; result filters wrap writing the response. Old ASP.NET MVC 5 had authentication filters too and no resource filters.

  Next questions, in Deep →Walk the storyboard →Excellon Software: filter types
• How do you register a filter, and how does it get services from DI?

  Globally: options.Filters.Add<AuditFilter>() in AddControllers. On a controller or action: an attribute, either a class deriving from ActionFilterAttribute, or [ServiceFilter(typeof(AuditFilter))] (gets it from DI, so it must be registered) or [TypeFilter(typeof(AuditFilter))] (creates it, filling the constructor from DI). Filters.Add<T>() and [TypeFilter] create a filter per request; [ServiceFilter] uses the lifetime you registered; Filters.Add(new AuditFilter()) adds one shared instance, which must hold no per-request state. Each way side by side: filter lifetime.

  Next questions, in Deep →Walk the incident →

Follow-up tree

Answer, then open the next level. That is the order an interviewer digs in.

Reporteda candidate was asked Intervieweran interviewer asks it

• ReportedWhat is the difference between middleware and filters?

  Middleware is part of the ASP.NET Core pipeline: it runs for every request and sees the HTTP request and response; after routing it can see which endpoint was chosen, but not the arguments or the result. Filters are part of MVC: they run only when a controller action handles the request, and they know which action, its arguments, the model state (the result of checking the bound parameters) and the result. Use middleware for things every request needs (HTTPS, CORS, authentication, global error handling, request logging), filters for things that depend on the action (auditing changes, mapping a domain exception, validation rules for some actions).

  Middleware: every request
    UseExceptionHandler
    UseAuthentication
    UseAuthorization
    MVC (only for controllers):
    authorization filters
    resource filters
    model binding
    action filters → action
    exception filters (on error)
    result filters → JSON

  Colan Infotech: middleware vs filters
• ReportedWhat are the filter types, and in which order do they run?

  Authorization, resource, action, exception, result. Authorization first; resource filters wrap model binding and everything after; action filters wrap the action; exception filters only when controller creation, model binding, an action filter or the action throws; result filters wrap writing the response. Old ASP.NET MVC 5 had authentication filters too and no resource filters.

  Walk the storyboard →Excellon Software: filter types
• How do you register a filter, and how does it get services from DI?

  Globally: options.Filters.Add<AuditFilter>() in AddControllers. On a controller or action: an attribute, either a class deriving from ActionFilterAttribute, or [ServiceFilter(typeof(AuditFilter))] (gets it from DI, so it must be registered) or [TypeFilter(typeof(AuditFilter))] (creates it, filling the constructor from DI). Filters.Add<T>() and [TypeFilter] create a filter per request; [ServiceFilter] uses the lifetime you registered; Filters.Add(new AuditFilter()) adds one shared instance, which must hold no per-request state. Each way side by side: filter lifetime.

  Walk the incident →
• How do you stop the action from running in a filter?

  Set context.Result in the before-method of an action or resource filter (or in an authorization filter). MVC skips the action and the remaining filters of that stage, and sends that result (result filters still run if an action filter set it). Throwing an exception instead is the wrong tool: it's slower and ends up as a 500.

  See it in Make it yours →
• Exception filter or exception middleware?

  For the global safety net, middleware: UseExceptionHandler with ProblemDetails (and an IExceptionHandler in .NET 8 and later) catches errors from everything after it in the pipeline, as long as the response hasn't started. Exception filters see errors from the action, the action filters, controller creation and model binding, but not from result execution or middleware, so I use one only to map specific domain exceptions, like ContractNotFoundException to 404. The global handler is its own card: global exception handling and logging.

• In which order do global, controller and action filters of the same type run?

  On the way in: global, then controller, then action. On the way out: the reverse, like layers of an onion. A filter that implements IOrderedFilter can set Order; lower numbers run first (on the way in), and with equal numbers, global runs first, then controller, then action.

• Should a filter implement IActionFilter or IAsyncActionFilter?

  Async when the filter awaits something, like a database call. IAsyncActionFilter has one method that gets next: code before await next() runs before the action, code after it runs after, and a local variable carries state between them, which also avoids the shared-field bug. Implement one of the two, not both: MVC only calls the async one.

• Do minimal APIs have filters?

  Yes, endpoint filters since .NET 7, for minimal APIs (endpoints written in Program.cs with no controller): IEndpointFilter, added with .AddEndpointFilter<T>() on a route. They wrap the handler like an action filter, with its arguments. MVC's five kinds are for controllers only. Worked example: endpoint filters.

Production bugs, and how to tell them

Each one: what you see, why, the fix in code, and the line to say.

• A serialization error skipped our exception filter: empty 500s

  HTTP/1.1 500 Internal Server Error
  Content-Length: 0
  
  System.Text.Json.JsonException: A possible
  object cycle was detected.

  Cause

  The team's ApiExceptionFilter turned exceptions into a ProblemDetails body (the standard error body) with a correlation id (an id that ties one request's log lines together). An action returned an EF Core entity (a class mapped to a database table) whose dealer pointed back to its contracts, a loop. The JSON writer threw while writing the response, during the result step. Exception filters only cover controller creation, model binding, action filters and the action, so the filter never saw it: the client got an empty 500 with nothing to quote to support.

  Fix

  Return a small DTO (a class shaped for the response) instead of the entity, which removes the loop. And move the safety net to middleware: UseExceptionHandler with ProblemDetails catches errors from anywhere in the pipeline. The exception filter stays only for mapping our own domain exceptions. How to write that handler, with a correlation id: global exception handling and logging.

  BeforeBeforeAfterAfter

  Diagram · step 1Before: the action returns the entity. No exception yet, so the exception filter isn't called.Show diagram

  MVCaction

  Filterours

  JSONwriter

  Catchouter

  Ok(contract entity)

  1// constructor: DI gives _contracts2public IActionResult Get(int id)3{4 var contract = _contracts.Find(id);5 return Ok(contract);6}

  Before · ContractsController.cs · line 5 · 1 of 1Returns the entity itself: dealer -> contracts -> dealer, a loop. Writing it as JSON throws.

  BackNext file

  Say it

  Exception filters only see errors from the controller, binding, action filters and the action. A JSON serialization error happens later, so ours never ran. Global error handling now lives in UseExceptionHandler, and filters only map domain exceptions.

• Every call to one controller failed with 500 after a refactor

  System.InvalidOperationException: No service
  for type 'AuditFilter' has been registered.

  Cause

  A developer moved AuditFilter from global to one controller with [ServiceFilter(typeof(AuditFilter))] (typeof(X) is the class X itself as a value). ServiceFilter asks the DI container for the filter, but nobody registered it there, so every call threw.

  Fix

  Register it (builder.Services.AddScoped<AuditFilter>()), or use [TypeFilter(typeof(AuditFilter))], which creates it without a registration and only uses DI for its constructor. A test calls one action of every controller at start-up.

  Lending.sln · where these 2 files sit

  • Controllers/
    • DealersController.cs
  • Program.cs

  BeforeAfter

  1[ServiceFilter(typeof(AuditFilter))]2public class DealersController3 : ControllerBase

  Before · DealersController.cs · line 1 · 1 of 1Gets AuditFilter from DI: it must be registered.

  BackNext file

  Say it

  ServiceFilter gets the filter from the DI container, so the filter itself must be registered. We registered it, and a smoke test calls every controller once.

Traps

• Don't sayFilters and middleware are the same thing.SayMiddleware runs for every request and sees only HTTP. Filters run only for controller actions and know the action, its arguments and its result.
• Don't sayAn exception filter catches every error in the app.SayOnly errors from controller creation, model binding, action filters and the action. Not middleware, resource or result filters, or writing the response. Use UseExceptionHandler for everything else.
• Don't sayStore the start time or the user in a field of the filter.SayA filter added as an instance is shared by all requests. Keep state in local variables (IAsyncActionFilter) or HttpContext.Items (a dictionary that lives for one request).
• Don't sayTo stop the action, throw from the filter.SaySet context.Result. MVC skips the action and the remaining filters of that stage, and sends that result.

Traps

What should you say instead? Tap to check.

• Don't sayFilters and middleware are the same thing.

  Say instead

  Middleware runs for every request and sees only HTTP. Filters run only for controller actions and know the action, its arguments and its result.

• Don't sayAn exception filter catches every error in the app.

  Say instead

  Only errors from controller creation, model binding, action filters and the action. Not middleware, resource or result filters, or writing the response. Use UseExceptionHandler for everything else.

• Don't sayStore the start time or the user in a field of the filter.

  Say instead

  A filter added as an instance is shared by all requests. Keep state in local variables (IAsyncActionFilter) or HttpContext.Items (a dictionary that lives for one request).

• Don't sayTo stop the action, throw from the filter.

  Say instead

  Set context.Result. MVC skips the action and the remaining filters of that stage, and sends that result.