ASP.NET Core MVC (and Razor Pages)

In short: Model–View–Controller separates an app into three parts.

• The Model holds data, business rules and validation (entities, view models).
• The View renders UI from a model (Razor .cshtml).
• The Controller receives the request, works with services and models, and returns a result (view, redirect, JSON).
• Benefits: separation of concerns, testable controllers, parallel work on UI and logic, and clean URLs through routing.

In short: Kestrel receives the request, which flows through the middleware pipeline (exception handling, HTTPS, static files, routing, authentication, authorisation).

• Endpoint routing selects the controller action.
• The controller is created via DI, then the filter pipeline runs: authorisation filters → resource filters → model binding and validation → action filters → the action executes → result filters → result execution (the view engine renders the view with its layout and partials).
• Exception filters handle errors in that stage, and the response goes back out through the middleware.

In short: ViewData is a string-keyed dictionary and ViewBag is a dynamic wrapper over the same data.

• Both live only for the current request (controller → view) and need no casting with ViewBag.
• TempData persists until it is read, typically across one redirect (PRG flash messages); it's stored in a cookie by default or in session.
• Keep()/Peek() retain values.
• Prefer strongly typed view models over all three for real data.

In short: Conventional routing defines URL templates centrally ({controller=Home}/{action=Index}/{id?}) and is good for uniform MVC apps.

• Attribute routing puts templates on controllers/actions ([Route("products/{id:int}")]), giving precise control, constraints and versioning;
• it's required for [ApiController].
• Both can coexist.
• Attribute routes are matched without the conventional patterns.

In short: The process of mapping HTTP request data (form fields, route values, query string, headers, body, files) to action parameters and model properties by name.

• Attributes [FromForm], [FromQuery], [FromRoute], [FromHeader], [FromBody] and [FromServices] control the source.
• After binding, validation runs and fills ModelState.

In short: Data annotations ([Required], [StringLength], [Range], [EmailAddress], [RegularExpression], [Compare]) on models are checked after model binding, and the results go into ModelState.

• Check ModelState.IsValid in the action and redisplay the view with errors.
• Tag helpers emit data-val-* attributes, so jQuery Unobtrusive Validation validates on the client too.
• Custom rules use a ValidationAttribute, IValidatableObject or FluentValidation.
• Server-side validation is mandatory because the client side can be bypassed.

In short: Use a partial view to reuse markup when the parent already has the data (e.g. a product card in a list).

• Use a view component when the widget needs its own logic and data from services, independent of the page's model (shopping cart badge, navigation menu, "latest posts").
• View components replace MVC 5 child actions and can be invoked as tag helpers (<vc:cart />).

In short: Filters run code at specific stages of the MVC action pipeline: Authorization → Resource → (model binding) → Action → action → Action (after) → Result → result execution → Result (after).

• Exception filters catch unhandled exceptions from these stages.
• They can be applied globally, per controller or per action (in that order on the way in), and use DI via ServiceFilter/TypeFilter.
• Use cases: auth, logging, caching, validation, error handling.

In short: Middleware is part of the ASP.NET Core pipeline.

• It runs for every request, including static files and non-MVC endpoints, works with HttpContext only, and its order is set in Program.cs.
• Filters are part of MVC.
• They run only for controller actions and Razor Pages, and can see MVC context such as ModelState, action arguments and IActionResult.
• Use middleware for cross-cutting HTTP concerns (logging, CORS, exception handling) and filters for action-specific concerns (validation, audit per action).

In short: Tag helpers are server-side C# classes that enhance HTML-looking elements via asp-* attributes (<input asp-for="Name" />, <a asp-action="Details" asp-route-id="5">).

• Compared with HTML helpers (@Html.TextBoxFor), they look like plain HTML, give better IntelliSense, are friendlier to designers, and add features automatically (antiforgery tokens in forms, cache-busting with asp-append-version).
• Custom tag helpers derive from TagHelper.

In short: Use antiforgery tokens.

• The form tag helper injects a hidden __RequestVerificationToken field paired with a cookie.
• Validate with [ValidateAntiForgeryToken] per action or globally with AutoValidateAntiforgeryTokenAttribute.
• For AJAX, send the token in a header (RequestVerificationToken) configured via AddAntiforgery(o => o.HeaderName = ...).
• SameSite cookies add defence in depth.
• APIs using JWT in the Authorization header aren't vulnerable in the same way.

In short: MVC apps usually use cookie authentication: after login (Identity or OpenID Connect via Entra ID), an encrypted auth cookie identifies the user on each request, and antiforgery tokens protect forms.

• Web APIs consumed by SPAs or mobile apps usually use JWT bearer tokens in the Authorization header, validated statelessly (issuer, audience, signature, expiry).
• In both, authorisation uses [Authorize] with roles, claims or policies.
• For SPAs, a BFF (Backend-for-Frontend) that keeps tokens server-side and uses cookies is now recommended for security.

In short: Defence in layers: (1) disable the button on submit with JavaScript;

• (2) use Post-Redirect-Get;
• (3) make the server idempotent — generate an order token (GUID) when rendering the form, store it in a hidden field, and enforce a unique constraint on it in the DB, so a second POST with the same token is rejected or returns the existing order.
• The DB unique constraint is the only fully reliable guard.

In short: It's an IDOR (Insecure Direct Object Reference) / broken access control.

• The action loads by ID without checking ownership.
• Fix: always scope queries by the current user (db.Orders.Where(o => o.Id == id && o.CustomerId == userId)), or use resource-based authorisation.
• Return 404 (not 403) to avoid revealing existence.
• Audit other endpoints, add integration tests for access control, and consider EF Core global query filters for multi-tenant data.