ASP.NET Core middleware

Een middleware-pijplijn maken met WebApplication

De ASP.NET Core-aanvraagpijplijn bestaat uit een reeks verzoekafgevaardigden, die achtereenvolgens worden aangeroepen. In het volgende diagram ziet u het concept. Het uitvoeringspad volgt de zwarte pijlen.

Elke gemachtigde kan bewerkingen uitvoeren voor en na de volgende gemachtigde. Gedelegeerden voor het afhandelen van uitzonderingen moeten vroeg in de pijplijn worden aangeroepen, zodat ze uitzonderingen kunnen ondervangen die zich in latere fasen van de pijplijn voordoen.

De eenvoudigste ASP.NET Core-app roept Run aan om een enkele terminal-middleware in te stellen als een anonieme functiegemachtigde om aanvragen te verwerken zonder een aanvraagpijplijn.

In het volgende voorbeeld:

• De aanroep naar RunExtensions.Run wordt bij elke aanvraag aangeroepen en schrijft 'Hello world!' naar het antwoord.
• De aanroep van WebApplication.Run aan het einde van het codeblok voert de app uit en blokkeert de aanroepende thread totdat de host wordt afgesloten.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello world!");
});

app.Run();

Antwoord bij het openen van de app in een browser bij de start-URL:

Hello world!

Koppel meerdere verzoekafgevaardigden aan elkaar met Use. De parameter next vertegenwoordigt de volgende gemachtigde in de pijplijn. Doorgaans kunt u acties uitvoeren vóór en na de next gemachtigde.

In het volgende voorbeeld ziet u:

• Twee Use oproepen, die elk naar de console schrijven:
  • Waar werk kan worden uitgevoerd dat naar het antwoord kan schrijven (context.Response, HttpResponse).
  • Waar werk kan worden uitgevoerd dat niet naar de respons schrijft nadat de next-parameter is aangeroepen.
• Een terminal aanvraag delegate met een aanroep naar RunExtensions.Run die "Hello world!" naar de response schrijft.
• Een laatste Use aanroep, die nooit wordt uitgevoerd omdat deze de gedelegeerde van de Run terminalaanvraag volgt.
• Een aanroep van WebApplication.Run aan het einde van het codeblok om de app te draaien en de aanroepende thread te blokkeren totdat de host afsluit.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Use(async (context, next) =>
{
    Console.WriteLine("Work that can write to the response. (1)");
    await next.Invoke(context);
    Console.WriteLine("Work that doesn't write to the response. (1)");
});

app.Use(async (context, next) =>
{
    Console.WriteLine("Work that can write to the response. (2)");
    await next.Invoke(context);
    Console.WriteLine("Work that doesn't write to the response. (2)");
});

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello world!");
});

app.Use(async (context, next) =>
{
    Console.WriteLine("This statement isn't reached. (3)");
    await next.Invoke(context);
    Console.WriteLine("This statement isn't reached. (3)");
});

app.Run();

In het consolevenster van de app wanneer de app wordt uitgevoerd:

Werk dat naar het antwoord kan schrijven. (1)
Werk dat naar het antwoord kan schrijven. (2)
Werk dat niet naar de reactie schrijft. (2)
Werk dat niet naar de reactie schrijft. (1)

Kortsluiting van de aanvraagpijplijn is vaak wenselijk omdat dit onnodig werk voorkomt. Middleware voor statische bestanden kan bijvoorbeeld fungeren als eindmiddleware door een verzoek om een statisch bestand te verwerken en de rest van de pijplijn kort te sluiten. Middleware die aan de pijplijn is toegevoegd voordat de terminal-middleware, blijft nog steeds code verwerken na hun next.Invoke instructies. Als u niet van plan bent om next.Invoke aan te roepen omdat u de pijplijn wilt beëindigen, gebruik een Run delegate in plaats van de Use extensiemethode aan te roepen.

Bel niet next.Invoke tijdens of nadat het antwoord naar de client is verzonden. Nadat een HttpResponse is gestart, resulteren wijzigingen in een uitzondering. Als u bijvoorbeeld headers of een antwoordstatuscode instelt, wordt er een uitzondering gegenereerd nadat het antwoord is gestart. Schrijven naar de hoofdtekst van het antwoord na het aanroepen next kan:

• Veroorzaakt een schending van een protocol, zoals het schrijven van meer bytes naar het antwoord dan de inhoudslengte van het opgegeven antwoord (Content-Length headerwaarde).
• Beschadig de bestandsindeling, zoals het schrijven van een HTML-voettekst naar een CSS-bestand.

Als u wilt bepalen of het antwoord is gestart, controleert u de waarde van HasStarted.

Zie Short-circuit middleware na routeringvoor meer informatie.

Run gemachtigde

Een Run gedelegeerde ontvangt geen next parameter. De eerste Run gemachtigde beëindigt altijd de pijplijn. Run is ook een conventie en sommige middleware kan methoden beschikbaar maken Run die aan het einde van de pijplijn worden uitgevoerd.

Eventuele Use- of Run-gedelegeerden na de eerste Run-gedelegeerde worden niet aangeroepen.

De middleware-pijplijn vertakken

Map-extensies worden gebruikt als conventie om de verwerkingspijplijn van aanvragen te vertakken. Map splitst de aanvraagpijplijn op basis van overeenkomende elementen van het opgegeven aanvraagpad. Als het aanvraagpad begint met het opgegeven pad, wordt de vertakking uitgevoerd.

In het volgende voorbeeld wordt HandleMap1 aangeroepen voor aanvragen aan /map1, en HandleMap2 wordt aangeroepen voor aanvragen aan /map2.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Map("/map1", HandleMap1);
app.Map("/map2", HandleMap2);

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from the non-Map delegate!");
});

app.Run();

private static void HandleMap1(IApplicationBuilder app)
{
    app.Run(async context =>
    {
        await context.Response.WriteAsync("Map 1");
    });
}

private static void HandleMap2(IApplicationBuilder app)
{
    app.Run(async context =>
    {
        await context.Response.WriteAsync("Map 2");
    });
}

In de volgende tabel ziet u de aanvragen en antwoorden met behulp van de voorgaande code.

Wanneer Map wordt gebruikt, worden de overeenkomende padsegmenten verwijderd uit HttpRequest.Path en toegevoegd aan HttpRequest.PathBase voor elke aanvraag.

Map kan in één keer overeenkomen met meerdere segmenten:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Map("/map1/segment1", HandleMultipleSegments);

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from the non-Map delegate.");
});

app.Run();

private static void HandleMultipleSegments(IApplicationBuilder app)
{
    app.Run(async context =>
    {
        await context.Response.WriteAsync("Processing '/map1/segment1'");
    });
}

In de volgende tabel ziet u de aanvragen en antwoorden met behulp van de voorgaande code.

Map biedt ondersteuning voor nesten:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Map("/level1", level1App => {
    level1App.Map("/level2a", level2AApp => {
        level2AApp.Run(async context =>
        {
            await context.Response.WriteAsync("Processing '/level1/level2a'");
        });
    });
    level1App.Map("/level2b", level2BApp => {
        level2BApp.Run(async context =>
        {
            await context.Response.WriteAsync("Processing '/level1/level2b'");
        });
    });
});

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from the non-Map delegate!");
});

app.Run();

In de volgende tabel ziet u de aanvragen en antwoorden met behulp van de voorgaande code.

MapWhen vertakt de aanvraagpijplijn op basis van het resultaat van het opgegeven predicaat. Elk predicaat van het type Func<HttpContext, bool> kan worden gebruikt om aanvragen toe te wijzen aan een nieuwe vertakking van de pijplijn. In het volgende voorbeeld wordt een predicaat gebruikt om de aanwezigheid van een queryreeksvariabele met de naam 'branch'' te detecteren:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapWhen(context => context.Request.Query.ContainsKey("branch"), HandleBranch);

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from the non-Map delegate.");
});

app.Run();

private static void HandleBranch(IApplicationBuilder app)
{
    app.Run(async context =>
    {
        var branchVer = context.Request.Query["branch"];
        await context.Response.WriteAsync($"Branch used = '{branchVer}'");
    });
}

In de volgende tabel ziet u de aanvragen en antwoorden met behulp van de voorgaande code.

UseWhen kan de aanvraagpijplijn vertakken op basis van het resultaat van het opgegeven predicaat. In tegenstelling tot MapWhen, wordt de vertakking opnieuw aan de hoofdpijplijn gekoppeld als deze geen terminal-middleware bevat:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseWhen(context => context.Request.Query.ContainsKey("branch"),
    appBuilder => HandleBranchAndRejoin(appBuilder));

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from the non-Map delegate.");
});

app.Run();

void HandleBranchAndRejoin(IApplicationBuilder app)
{
    var logger = app.ApplicationServices.GetRequiredService<ILogger<Program>>(); 

    app.Use(async (context, next) =>
    {
        var branchVer = context.Request.Query["branch"];
        logger.LogInformation("Branch used = {branchVer}", branchVer.ToString());

        Console.WriteLine("Work that can write to the response.");
        await next.Invoke(context);
        Console.WriteLine("Work that doesn't write to the response.");
    });
}

In het voorgaande voorbeeld wordt een antwoord van 'Hello from the non-Map delegate.' geschreven voor alle aanvragen. Als de aanvraag een queryreeksvariabele met de naam 'branch' bevat, wordt de waarde vastgelegd voordat de hoofdpijplijn opnieuw wordt toegevoegd.

Een middleware-pijplijn maken met IApplicationBuilder

De ASP.NET Core-aanvraagpijplijn bestaat uit een reeks verzoekafgevaardigden, die achtereenvolgens worden aangeroepen. In het volgende diagram ziet u het concept. Het uitvoeringspad volgt de zwarte pijlen.

Elke gemachtigde kan bewerkingen uitvoeren voor en na de volgende gemachtigde. Gedelegeerden voor het afhandelen van uitzonderingen moeten vroeg in de pijplijn worden aangeroepen, zodat ze uitzonderingen kunnen ondervangen die zich in latere fasen van de pijplijn voordoen.

De eenvoudigst mogelijke ASP.NET Core-app stelt een enkele verzoekafgevaardigde in die alle verzoeken afhandelt. In dit geval is er geen daadwerkelijke aanvraagpijplijn aanwezig. In plaats daarvan wordt één anonieme functie aangeroepen als reactie op elke HTTP-aanvraag.

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello, World!");
        });
    }
}

Koppel meerdere verzoekafgevaardigden aan elkaar met Use. De parameter next vertegenwoordigt de volgende gemachtigde in de pijplijn. U kunt de pijplijn kortsluiten door niet de volgende parameter aan te roepen. Doorgaans kunt u acties uitvoeren voor en na de volgende gemachtigde, zoals in het volgende voorbeeld wordt gedemonstreerde:

app.Use(async (context, next) =>
{
    // Do work that doesn't write to the Response.
    await next.Invoke();
    // Do logging or other work that doesn't write to the Response.
});

Wanneer een gemachtigde een aanvraag niet doorgeeft aan de volgende gemachtigde, heet dat het verzoekenpijplijn omzeilen. Kortsluiting is vaak wenselijk omdat het onnodig werk vermijdt. Middleware voor statische bestanden kan bijvoorbeeld fungeren als eindmiddleware door een verzoek om een statisch bestand te verwerken en de rest van de pijplijn kort te sluiten. Middleware toegevoegd aan de pijplijn vóór de middleware die verdere verwerking beëindigt, blijft code verwerken na hun next.Invoke instructies. Zie echter de volgende waarschuwing over het proberen te schrijven naar een antwoord dat al is verzonden.

Run afgevaardigden ontvangen geen next parameter. De eerste Run gedelegeerde is altijd terminal en beëindigt de pijplijn. Run is een conventie. Sommige middlewareonderdelen kunnen Run[Middleware] methoden beschikbaar maken die aan het einde van de pijplijn worden uitgevoerd:

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from 2nd delegate.");
});

In het vorige voorbeeld schrijft de Run delegate "Hello from 2nd delegate." naar de respons en beëindigt de pijplijn. Als er een andere Use of Run delegate wordt toegevoegd na de Run delegate, wordt deze niet aangeroepen.

De middleware-pijplijn vertakken

Map extensies worden gebruikt als een conventie voor het vertakken van de pijplijn. Map splitst de aanvraagpijplijn op basis van overeenkomende elementen van het opgegeven aanvraagpad. Als het aanvraagpad begint met het opgegeven pad, wordt de vertakking uitgevoerd.

public class Startup
{
    private static void HandleMapTest1(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Map Test 1");
        });
    }

    private static void HandleMapTest2(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Map Test 2");
        });
    }

    public void Configure(IApplicationBuilder app)
    {
        app.Map("/map1", HandleMapTest1);

        app.Map("/map2", HandleMapTest2);

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from non-Map delegate.");
        });
    }
}

In de volgende tabel ziet u de aanvragen en antwoorden van http://localhost:1234 met behulp van de vorige code.

Wanneer Map wordt gebruikt, worden de overeenkomende padsegmenten verwijderd uit HttpRequest.Path en toegevoegd aan HttpRequest.PathBase voor elke aanvraag.

Map ondersteunt nesten, bijvoorbeeld:

app.Map("/level1", level1App => {
    level1App.Map("/level2a", level2AApp => {
        // "/level1/level2a" processing
    });
    level1App.Map("/level2b", level2BApp => {
        // "/level1/level2b" processing
    });
});

Map kan ook meerdere segmenten tegelijk overeenkomen:

public class Startup
{
    private static void HandleMultiSeg(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Map multiple segments.");
        });
    }

    public void Configure(IApplicationBuilder app)
    {
        app.Map("/map1/seg1", HandleMultiSeg);

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from non-Map delegate.");
        });
    }
}

MapWhen vertakt de aanvraagpijplijn op basis van het resultaat van het opgegeven predicaat. U kunt elk predicaat van het type Func<HttpContext, bool> gebruiken om aanvragen toe te wijzen aan een nieuwe vertakking van de pijplijn. In het volgende voorbeeld detecteert een predicaat de aanwezigheid van een queryreeksvariabele branch:

public class Startup
{
    private static void HandleBranch(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            var branchVer = context.Request.Query["branch"];
            await context.Response.WriteAsync($"Branch used = {branchVer}");
        });
    }

    public void Configure(IApplicationBuilder app)
    {
        app.MapWhen(context => context.Request.Query.ContainsKey("branch"),
                               HandleBranch);

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from non-Map delegate.");
        });
    }
}

In de volgende tabel ziet u de aanvragen en antwoorden van http://localhost:1234 met behulp van de vorige code.

UseWhen vertakt ook de aanvraagpijplijn op basis van het resultaat van het opgegeven predicaat. In tegenstelling tot MapWhen, wordt deze vertakking opnieuw aan de hoofdpijplijn gekoppeld als deze niet onderbroken wordt of geen terminal-middleware bevat.

public class Startup
{
    private void HandleBranchAndRejoin(IApplicationBuilder app, ILogger<Startup> logger)
    {
        app.Use(async (context, next) =>
        {
            var branchVer = context.Request.Query["branch"];
            logger.LogInformation("Branch used = {branchVer}", branchVer.ToString());

            // Do work that doesn't write to the Response.
            await next();
            // Do other work that doesn't write to the Response.
        });
    }

    public void Configure(IApplicationBuilder app, ILogger<Startup> logger)
    {
        app.UseWhen(context => context.Request.Query.ContainsKey("branch"),
                               appBuilder => HandleBranchAndRejoin(appBuilder, logger));

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from main pipeline.");
        });
    }
}

In het voorgaande voorbeeld wordt een antwoord van 'Hello from main pipeline' geschreven voor alle aanvragen. Als de aanvraag een queryreeksvariabele bevat branch, wordt de waarde vastgelegd voordat de hoofdpijplijn opnieuw wordt toegevoegd.

Middleware automatisch toegevoegd door WebApplication

if (isDevelopment)
{
    app.UseDeveloperExceptionPage();
}

app.UseRouting();

if (isAuthenticationConfigured)
{
    app.UseAuthentication();
}

if (isAuthorizationConfigured)
{
    app.UseAuthorization();
}

// user middleware/endpoints
app.CustomMiddleware(...);
app.MapGet("/", () => "hello world");
// end user middleware/endpoints

app.UseEndpoints(e => {});

app.UseCors();
app.UseAuthentication();
app.UseAuthorization();

app.Use((context, next) =>
{
    return next(context);
});

app.UseRouting();

// other middleware and endpoints

app.UseRouting();

app.MapGet("/", () => "hello world");

app.UseEndpoints(e => {});

app.Run(context =>
{
    context.Response.StatusCode = 404;
    return Task.CompletedTask;
});

if (isDevelopment)
{
    app.UseDeveloperExceptionPage();
}

app.UseRouting();

if (isAuthenticationConfigured)
{
    app.UseAuthentication();
}

if (isAuthorizationConfigured)
{
    app.UseAuthorization();
}

// User middleware/endpoints
app.CustomMiddleware(...);
app.MapGet("/", () => "hello world");
// End user middleware/endpoints

app.UseEndpoints(e => {});

app.UseCors();
app.UseAuthentication();
app.UseAuthorization();

app.Use((context, next) =>
{
    return next(context);
});

app.UseRouting();

// Other middleware and endpoints

app.UseRouting();

app.MapGet("/", () => "hello world");

app.UseEndpoints(e => {});

app.Run(context =>
{
    context.Response.StatusCode = 404;
    return Task.CompletedTask;
});

De volgorde waarin middleware wordt weergegeven in het Program-bestand van de app, bepaalt de volgorde waarin middleware worden aangeroepen bij een verzoek, met de omgekeerde volgorde voor de respons.

U hebt volledige controle over de volgorde van middleware en de mogelijkheid om aangepaste middleware toe te voegen voor aanvraagverwerkingsscenario's. Houd er rekening mee dat de volgorde van middleware essentieel kan zijn voor beveiliging, prestaties en functionaliteit.

In de volgende voorbeelden ziet u de middlewarevolgorde voor veelvoorkomende app-scenario's. Elke middleware-extensiemethode wordt via de WebApplicationBuilder naamruimte op Microsoft.AspNetCore.Builder aangeboden:

1. Uitzonderings- en foutafhandeling
   • Wanneer de app wordt uitgevoerd in de Development omgeving:
     • Middleware voor de ontwikkelaarsexceptiepagina (UseDeveloperExceptionPage) rapporteert runtimefouten in de app.
     • Middleware voor databasefoutpagina’s (UseDatabaseErrorPage) meldt runtimefouten in de database.
   • Wanneer de app wordt uitgevoerd in de Production omgeving:
     • Middleware voor uitzonderingsafhandeling (UseExceptionHandler) onderschept uitzonderingen die in de volgende middleware worden gegenereerd.
     • Http Strict Transport Security (HSTS) protocol middleware (UseHsts) voegt de Strict-Transport-Security header toe.
2. MET HTTPS-omleidings-middleware (UseHttpsRedirection) worden HTTP-aanvragen omgeleid naar HTTPS.
3. Middleware voor statische bestanden (indien nodig, UseStaticFiles) serveert statische bestanden en stopt verdere verwerking van de aanvraag.
4. Cookie policy middleware (UseCookiePolicy) brengt de app in overeenstemming met de Algemene verordening gegevensbescherming (AVG).
5. Routeringsmiddleware (UseRouting) om verzoeken te routeren.
6. Verificatie-middleware (UseAuthentication) probeert de gebruiker te verifiëren voordat ze toegang krijgen tot beveiligde resources.
7. Met autorisatie-middleware (UseAuthorization) kan een gebruiker toegang krijgen tot beveiligde resources.
8. Antiforgery middleware (UseAntiforgery) voegt antiforgery-middleware toe aan de pijplijn. UseAntiforgery moet worden geplaatst na aanroepen van UseAuthentication en UseAuthorization.
9. Sessie-middleware (Razor alleen voor Pages en MVC, UseSession) stelt de sessiestatus vast en onderhoudt deze. Als de app sessiestatus gebruikt, roept u sessie-middleware aan na cookie beleids-middleware en vóór Razor Pages/MVC middleware.
10. Middleware voor eindpuntroutering

• MapRazorComponents om onderdeeleindpunten Razor toe te voegen aan de request pipeline.
• MapRazorPages om pagina-eindpunten toe te voegen Razor aan de aanvraagpijplijn.
• MapControllerRoute om controllereindpunten toe te voegen aan de aanvraagpijplijn.

Typische Blazor Web App middleware-pijplijn:

app.UseWebAssemblyDebugging(); // Development environment with client-side rendering
app.UseMigrationsEndPoint(); // Development environment with ASP.NET Core Identity

app.UseExceptionHandler("/Error", createScopeForErrors: true); // Non-Development environment
app.UseHsts(); // Non-Development environment with HTTPS protocol

app.UseStatusCodePagesWithReExecute("/not-found", createScopeForStatusCodePages: true);

app.UseHttpsRedirection(); // With HTTPS protocol

app.UseAntiforgery();

app.MapStaticAssets();

app.MapRazorComponents<App>(); // With additional extension methods for render modes

app.MapAdditionalIdentityEndpoints(); // With ASP.NET Core Identity

app.Run();

Typische Razor Pages/MVC-middleware pipeline:

app.UseMigrationsEndPoint(); // Development environment with ASP.NET Core Identity

app.UseExceptionHandler("/Error"); // Non-Development environment
app.UseHsts(); // Non-Development environment with HTTPS protocol

app.UseHttpsRedirection(); // With HTTPS protocol

// app.UseCookiePolicy();
app.UseRouting(); // If not called, runs at the beginning of the pipeline by default
// app.UseRateLimiter();
// app.UseRequestLocalization();
// app.UseCors();

// app.UseAuthentication(); // Called internally for ASP.NET Core Identity
app.UseAuthorization();
// app.UseSession();
// app.UseResponseCompression();
// app.UseResponseCaching();

app.MapStaticAssets();

app.MapControllerRoute(...); // For MVC controllers

app.MapRazorPages(); // For Razor Pages pages

app.MapControllers(); // With authentication in a Razor Pages app

app.Run();

In de voorgaande code:

• CORS-middleware (UseCors), verificatie-middleware (UseAuthentication) en autorisatie-middleware (UseAuthorization) moeten worden weergegeven in de weergegeven volgorde.
• CORS-middleware (UseCors) moet vóór middleware voor antwoordcache (UseResponseCaching) komen om CORS-headers toe te voegen aan elk verzoek, inclusief in de cache opgeslagen antwoorden. Zie Het is niet duidelijk dat UseCORS vóór UseResponseCaching (dotnet/aspnetcore #23218) moet komen voor meer informatie.
• Middleware voor aanvraaglokalisatie (UseRequestLocalization) moet vóór middleware komen die mogelijk de cultuur van de aanvraag controleert, bijvoorbeeld middleware voor statische bestanden (UseStaticFiles).
• Middleware voor snelheidsbeperking (UseRateLimiter) moet worden aangeroepen na routeringsmiddleware (UseRouting) wanneer eindpuntspecifieke API's voor snelheidsbeperking worden gebruikt. Als het [EnableRateLimiting] kenmerk bijvoorbeeld wordt gebruikt, moet de snelheidsbeperkings-middleware worden aangeroepen na het routeren van middleware. Wanneer u alleen globale limieten aanroept, kunnen middleware voor snelheidsbeperking worden aangeroepen voordat middleware voor routering wordt aangeroepen.

In sommige scenario's heeft middleware een andere volgorde. De volgorde van caching en compressie is bijvoorbeeld afhankelijk van de specificatie van de app. In de volgende volgorde kan het CPU-gebruik worden verminderd door het gecomprimeerde antwoord in de cache te plaatsen, maar de app kan uiteindelijk meerdere weergaven van een resource opslaan met behulp van verschillende compressiealgoritmen, zoals Gzip of Brotli:

app.UseResponseCaching();
app.UseResponseCompression();

Statische assets worden doorgaans vroeg in de pijplijn geleverd, zodat de app de aanvraagverwerking kan omzeilen om de prestaties te verbeteren.

Authenticatie omzeilt geen niet-geauthenticeerde verzoeken. Hoewel verificatie-middleware aanvragen verifieert, vindt autorisatie plaats nadat het framework een Razor onderdeel in een Blazor Web App, een pagina in een Razor Pagina-app of een controller en actie in een MVC-app selecteert.

In het volgende diagram ziet u de volledige pijplijn voor het verwerken van aanvragen voor ASP.NET Core MVC en Razor Pages-apps. U kunt zien hoe in een typische app bestaande middlewares worden geordend en waar aangepaste middlewares worden toegevoegd. U hebt volledige controle over het opnieuw ordenen van bestaande middlewares of het invoeren van nieuwe aangepaste middlewares, indien nodig voor uw scenario's.

De Endpoint middleware in het voorgaande diagram voert de filterpijplijn uit voor het bijbehorende app-type: MVC of Razor Pages.

In het voorgaande diagram wordt de middleware Routing weergegeven na Statische bestanden. Deze volgorde is de manier waarop de projectsjablonen werken, doordat app.UseRouting expliciet wordt aangeroepen. Als u app.UseRoutingniet aanroept, wordt de Routing middleware standaard uitgevoerd aan het begin van de pijplijn. Zie Routingvoor meer informatie.

De volgorde waarin u middlewareonderdelen in het Program.cs bestand toevoegt, definieert de volgorde waarin de middleware-onderdelen worden aangeroepen voor aanvragen en de omgekeerde volgorde voor het antwoord. De volgorde is kritieke voor beveiliging, prestaties en functionaliteit.

De volgende gemarkeerde code in Program.cs voegt beveiligingsgerelateerde middlewareonderdelen toe in de gebruikelijke aanbevolen volgorde:

using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;
using WebMiddleware.Data;

var builder = WebApplication.CreateBuilder(args);

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection")
    ?? throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();

builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseMigrationsEndPoint();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
// app.UseCookiePolicy();

app.UseRouting();
// app.UseRateLimiter();
// app.UseRequestLocalization();
// app.UseCors();

app.UseAuthentication();
app.UseAuthorization();
// app.UseSession();
// app.UseResponseCompression();
// app.UseResponseCaching();

app.MapRazorPages();
app.MapDefaultControllerRoute();

app.Run();

In de voorgaande code:

• Uitgecommentarieerde middleware wordt niet toegevoegd wanneer u een nieuwe web-app maakt met afzonderlijke gebruikersaccounts.
• Niet elke middleware wordt in deze exacte volgorde weergegeven, maar veel wel. Bijvoorbeeld:
  • UseCors, UseAuthenticationen UseAuthorization moeten worden weergegeven in de weergegeven volgorde.
  • UseCors moet momenteel eerst komen voordat UseResponseCaching. Deze vereiste wordt uitgelegd in probleem dotnet/aspnetcore #23218van GitHub.
  • UseRequestLocalization moet vóór middleware staan die de aanvraagcultuur kan controleren, bijvoorbeeld app.UseStaticFiles().
  • UseRateLimiter moet worden aangeroepen na UseRouting wanneer eindpuntspecifieke API's voor frequentiebeperking worden gebruikt. Als het kenmerk [EnableRateLimiting] bijvoorbeeld wordt gebruikt, moet UseRateLimiter worden aangeroepen na UseRouting. Wanneer u alleen globale begrenzers aanroept, kan UseRateLimiter worden aangeroepen voordat UseRouting.

In sommige scenario's heeft middleware een andere volgorde. Caching en compressievolgorde zijn bijvoorbeeld scenariospecifiek en er zijn meerdere geldige volgordes. Bijvoorbeeld:

app.UseResponseCaching();
app.UseResponseCompression();

Met de voorgaande code kunt u het CPU-gebruik verminderen door het gecomprimeerde antwoord in de cache te plaatsen, maar u kunt uiteindelijk meerdere weergaven van een resource opslaan met behulp van verschillende compressiealgoritmen zoals Gzip of Brotli.

In de volgende volgorde worden statische bestanden gecombineerd om gecomprimeerde statische bestanden in de cache toe te staan:

app.UseResponseCaching();
app.UseResponseCompression();
app.UseStaticFiles();

Met de volgende Program.cs code worden middlewareonderdelen toegevoegd voor veelvoorkomende app-scenario's:

1. Uitzonderings- en foutafhandeling
   • Wanneer de app wordt uitgevoerd in de Development omgeving:
     • Middleware voor de ontwikkelaarsexceptiepagina (UseDeveloperExceptionPage) rapporteert runtimefouten in de app.
     • Middleware voor databasefoutpagina’s (UseDatabaseErrorPage) meldt runtimefouten in de database.
   • Wanneer de app wordt uitgevoerd in de Production omgeving:
     • Middleware voor uitzonderingsafhandeling (UseExceptionHandler) onderschept uitzonderingen die in de volgende middleware worden gegenereerd.
     • Http Strict Transport Security (HSTS) protocol middleware (UseHsts) voegt de Strict-Transport-Security header toe.
2. MET HTTPS-omleidings-middleware (UseHttpsRedirection) worden HTTP-aanvragen omgeleid naar HTTPS.
3. Middleware voor statische bestanden (UseStaticFiles) geeft statische bestanden terug en voorkomt verdere aanvraagverwerking.
4. Cookie beleidsmiddleware (UseCookiePolicy) brengt de app in overeenstemming met de AVG-regelgeving van de EU.
5. Routeringsmiddleware (UseRouting) om verzoeken te routeren.
6. Verificatie-middleware (UseAuthentication) probeert de gebruiker te verifiëren voordat ze toegang krijgen tot beveiligde resources.
7. Met autorisatie-middleware (UseAuthorization) kan een gebruiker toegang krijgen tot beveiligde resources.
8. Sessie-middleware (UseSession) brengt de sessiestatus tot stand en onderhoudt deze. Als de app de sessiestatus gebruikt, roept u sessie-middleware aan na cookie beleids-middleware en vóór MVC-middleware.
9. Middleware voor eindpuntroutering (UseEndpoints met MapRazorPages) om Razor Pages-eindpunten toe te voegen aan de aanvraagverwerkingspipeline.

if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
    app.UseDatabaseErrorPage();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseCookiePolicy();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseSession();
app.MapRazorPages();

In de voorgaande voorbeeldcode wordt elke middleware-extensiemethode weergegeven op WebApplicationBuilder via de Microsoft.AspNetCore.Builder naamruimte.

UseExceptionHandler is het eerste middlewareonderdeel dat aan de pijplijn is toegevoegd. Daarom vangt de middleware voor uitzonderingsafhandeling eventuele uitzonderingen op die optreden in latere aanroepen.

Middleware voor statische bestanden wordt vroeg in de pijplijn aangeroepen, zodat deze verzoeken kan afhandelen en de verwerking kan afbreken zonder door de overige componenten te gaan. De statische bestands-middleware biedt geen autorisatiecontroles. Alle bestanden die worden geleverd door statische bestands-middleware, inclusief bestanden onder wwwroot, zijn openbaar beschikbaar. Zie Statische bestanden serveren in ASP.NET Core Apps voor een benadering voor het beveiligen van statische bestanden.

Als de aanvraag niet wordt verwerkt door de statische bestands-middleware, wordt deze doorgegeven aan de verificatie-middleware (UseAuthentication), waarmee verificatie wordt uitgevoerd. Authenticatie omzeilt geen niet-geauthenticeerde verzoeken. Hoewel verificatie-middleware aanvragen verifieert, vindt autorisatie (en afwijzing) alleen plaats nadat MVC een specifieke Razor pagina of MVC-controller en -actie heeft geselecteerd.

In het volgende voorbeeld ziet u een middlewarevolgorde waarin aanvragen voor statische bestanden worden verwerkt door statische bestands-middleware voordat middleware voor reactiecompressie wordt verwerkt. Statische bestanden worden niet gecomprimeerd met deze middlewarevolgorde. De reacties van de Razor-pagina kunnen worden gecomprimeerd.

// Static files aren't compressed by static file middleware.
app.UseStaticFiles();

app.UseRouting();

app.UseResponseCompression();

app.MapRazorPages();

In het volgende diagram ziet u de volledige pijplijn voor het verwerken van aanvragen voor ASP.NET Core MVC en Razor Pages-apps. U kunt zien hoe in een typische app bestaande middlewares worden geordend en waar aangepaste middlewares worden toegevoegd. U hebt volledige controle over het opnieuw ordenen van bestaande middlewares of het invoeren van nieuwe aangepaste middlewares, indien nodig voor uw scenario's.

De Endpoint middleware in het voorgaande diagram voert de filterpijplijn uit voor het bijbehorende app-type: MVC of Razor Pages.

In het voorgaande diagram wordt de middleware Routing weergegeven na Statische bestanden. Deze volgorde is de manier waarop de projectsjablonen werken, doordat app.UseRouting expliciet wordt aangeroepen. Als u app.UseRoutingniet aanroept, wordt de Routing middleware standaard uitgevoerd aan het begin van de pijplijn. Zie Routingvoor meer informatie.

De volgorde waarin u middlewareonderdelen in het Program.cs bestand toevoegt, definieert de volgorde waarin de middleware-onderdelen worden aangeroepen voor aanvragen en de omgekeerde volgorde voor het antwoord. De volgorde is kritieke voor beveiliging, prestaties en functionaliteit.

De volgende gemarkeerde code in Program.cs voegt beveiligingsgerelateerde middlewareonderdelen toe in de gebruikelijke aanbevolen volgorde:

using IndividualAccountsExample.Data;
using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();

builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddRazorPages();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseMigrationsEndPoint();
}
else
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
// app.UseCookiePolicy();

app.UseRouting();
// app.UseRequestLocalization();
// app.UseCors();

app.UseAuthentication();
app.UseAuthorization();
// app.UseSession();
// app.UseResponseCompression();
// app.UseResponseCaching();

app.MapRazorPages();
app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

In de voorgaande code:

• Uitgecommentarieerde middleware wordt niet toegevoegd wanneer u een nieuwe web-app maakt met afzonderlijke gebruikersaccounts.
• Niet elke middleware wordt in deze exacte volgorde weergegeven, maar veel wel. Bijvoorbeeld:
  • UseCors, UseAuthenticationen UseAuthorization moeten worden weergegeven in de weergegeven volgorde.
  • UseCors moet momenteel eerst komen voordat UseResponseCaching. Deze vereiste wordt uitgelegd in probleem dotnet/aspnetcore #23218van GitHub.
  • UseRequestLocalization moet worden weergegeven vóór middleware die de aanvraagcultuur kan controleren (bijvoorbeeld app.UseMvcWithDefaultRoute()).

In sommige scenario's heeft middleware een andere volgorde. Caching en compressievolgorde zijn bijvoorbeeld scenariospecifiek en er zijn meerdere geldige volgordes. Bijvoorbeeld:

app.UseResponseCaching();
app.UseResponseCompression();

Met de voorgaande code kunt u het CPU-gebruik verminderen door het gecomprimeerde antwoord in de cache te plaatsen, maar u kunt uiteindelijk meerdere weergaven van een resource opslaan met behulp van verschillende compressiealgoritmen zoals Gzip of Brotli.

In de volgende volgorde worden statische bestanden gecombineerd om gecomprimeerde statische bestanden in de cache toe te staan:

app.UseResponseCaching();
app.UseResponseCompression();
app.UseStaticFiles();

Met de volgende Program.cs code worden middlewareonderdelen toegevoegd voor veelvoorkomende app-scenario's:

1. Uitzonderings- en foutafhandeling
   • Wanneer de app wordt uitgevoerd in de Development omgeving:
     • Middleware voor de ontwikkelaarsexceptiepagina (UseDeveloperExceptionPage) rapporteert runtimefouten in de app.
     • Middleware voor databasefoutpagina’s (UseDatabaseErrorPage) meldt runtimefouten in de database.
   • Wanneer de app wordt uitgevoerd in de Production omgeving:
     • Middleware voor uitzonderingsafhandeling (UseExceptionHandler) onderschept uitzonderingen die in de volgende middleware worden gegenereerd.
     • Http Strict Transport Security (HSTS) protocol middleware (UseHsts) voegt de Strict-Transport-Security header toe.
2. MET HTTPS-omleidings-middleware (UseHttpsRedirection) worden HTTP-aanvragen omgeleid naar HTTPS.
3. Middleware voor statische bestanden (UseStaticFiles) geeft statische bestanden terug en voorkomt verdere aanvraagverwerking.
4. Cookie beleidsmiddleware (UseCookiePolicy) brengt de app in overeenstemming met de AVG-regelgeving van de EU.
5. Routeringsmiddleware (UseRouting) om verzoeken te routeren.
6. Verificatie-middleware (UseAuthentication) probeert de gebruiker te verifiëren voordat ze toegang krijgen tot beveiligde resources.
7. Met autorisatie-middleware (UseAuthorization) kan een gebruiker toegang krijgen tot beveiligde resources.
8. Sessie-middleware (UseSession) brengt de sessiestatus tot stand en onderhoudt deze. Als de app de sessiestatus gebruikt, roept u sessie-middleware aan na cookie beleids-middleware en vóór MVC-middleware.
9. Middleware voor eindpuntroutering (UseEndpoints met MapRazorPages) om Razor Pages-eindpunten toe te voegen aan de aanvraagverwerkingspipeline.

if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
    app.UseDatabaseErrorPage();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseCookiePolicy();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseSession();
app.MapRazorPages();

In de voorgaande voorbeeldcode wordt elke middleware-extensiemethode weergegeven op WebApplicationBuilder via de Microsoft.AspNetCore.Builder naamruimte.

UseExceptionHandler is het eerste middlewareonderdeel dat aan de pijplijn is toegevoegd. Daarom vangt de middleware voor uitzonderingsafhandeling eventuele uitzonderingen op die optreden in latere aanroepen.

Middleware voor statische bestanden wordt vroeg in de pijplijn aangeroepen, zodat deze verzoeken kan afhandelen en de verwerking kan afbreken zonder door de overige componenten te gaan. De statische bestands-middleware biedt geen autorisatiecontroles. Alle bestanden die worden geleverd door statische bestands-middleware, inclusief bestanden onder wwwroot, zijn openbaar beschikbaar. Zie Statische bestanden serveren in ASP.NET Core Apps voor een benadering voor het beveiligen van statische bestanden.

Als de aanvraag niet wordt verwerkt door de statische bestands-middleware, wordt deze doorgegeven aan de verificatie-middleware (UseAuthentication), waarmee verificatie wordt uitgevoerd. Authenticatie omzeilt geen niet-geauthenticeerde verzoeken. Hoewel verificatie-middleware aanvragen verifieert, vindt autorisatie (en afwijzing) alleen plaats nadat MVC een specifieke Razor pagina of MVC-controller en -actie heeft geselecteerd.

In het volgende voorbeeld ziet u een middlewarevolgorde waarin aanvragen voor statische bestanden worden verwerkt door statische bestands-middleware voordat middleware voor reactiecompressie wordt verwerkt. Statische bestanden worden niet gecomprimeerd met deze middlewarevolgorde. De reacties van de Razor-pagina kunnen worden gecomprimeerd.

// Static files aren't compressed by static file middleware.
app.UseStaticFiles();

app.UseRouting();

app.UseResponseCompression();

app.MapRazorPages();

In het volgende diagram ziet u de volledige pijplijn voor het verwerken van aanvragen voor ASP.NET Core MVC en Razor Pages-apps. U kunt zien hoe in een typische app bestaande middlewares worden geordend en waar aangepaste middlewares worden toegevoegd. U hebt volledige controle over het opnieuw ordenen van bestaande middlewares of het invoeren van nieuwe aangepaste middlewares, indien nodig voor uw scenario's.

De Endpoint middleware in het voorgaande diagram voert de filterpijplijn uit voor het bijbehorende app-type: MVC of Razor Pages.

De volgorde waarin middlewareonderdelen worden toegevoegd in de methode Startup.Configure definieert de volgorde waarin de middleware-onderdelen worden aangeroepen voor aanvragen en de omgekeerde volgorde voor het antwoord. De volgorde is kritieke voor beveiliging, prestaties en functionaliteit.

Met de volgende Startup.Configure methode worden beveiligingsgerelateerde middlewareonderdelen toegevoegd in de gebruikelijke aanbevolen volgorde:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseDatabaseErrorPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();
    // app.UseCookiePolicy();

    app.UseRouting();
    // app.UseRequestLocalization();
    // app.UseCors();

    app.UseAuthentication();
    app.UseAuthorization();
    // app.UseSession();
    // app.UseResponseCompression();
    // app.UseResponseCaching();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
        endpoints.MapControllerRoute(
            name: "default",
            pattern: "{controller=Home}/{action=Index}/{id?}");
    });
}

In de voorgaande code:

• Uitgecommentarieerde middleware wordt niet toegevoegd wanneer u een nieuwe web-app maakt met afzonderlijke gebruikersaccounts.
• Niet elke middleware wordt in deze exacte volgorde weergegeven, maar veel wel. Bijvoorbeeld:
  • UseCors, UseAuthenticationen UseAuthorization moeten worden weergegeven in de weergegeven volgorde.
  • UseCors moet momenteel vanwege UseResponseCachingworden weergegeven voordat .
  • UseRequestLocalization moet worden weergegeven vóór middleware die de aanvraagcultuur kan controleren (bijvoorbeeld app.UseMvcWithDefaultRoute()).

In sommige scenario's heeft middleware een andere volgorde. Caching en compressievolgorde zijn bijvoorbeeld scenariospecifiek en er zijn meerdere geldige volgordes. Bijvoorbeeld:

app.UseResponseCaching();
app.UseResponseCompression();

Met de voorgaande code kan CPU-besparing worden bereikt door het gecomprimeerde antwoord in de cache op te slaan, maar het kan gebeuren dat u meerdere representaties van een resource in de cache opslaat met behulp van compressiealgoritmen zoals Gzip of Brotli.

In de volgende volgorde worden statische bestanden gecombineerd om gecomprimeerde statische bestanden in de cache toe te staan:

app.UseResponseCaching();
app.UseResponseCompression();
app.UseStaticFiles();

Met de volgende Startup.Configure methode worden middlewareonderdelen toegevoegd voor veelvoorkomende app-scenario's:

1. Uitzonderings- en foutafhandeling
   • Wanneer de app wordt uitgevoerd in de Development omgeving:
     • Middleware voor de ontwikkelaarsexceptiepagina (UseDeveloperExceptionPage) rapporteert runtimefouten in de app.
     • Middleware voor databasefoutpagina's meldt runtimefouten in de database.
   • Wanneer de app wordt uitgevoerd in de Production omgeving:
     • Middleware voor uitzonderingsafhandeling (UseExceptionHandler) onderschept uitzonderingen die in de volgende middleware worden gegenereerd.
     • Http Strict Transport Security (HSTS) protocol middleware (UseHsts) voegt de Strict-Transport-Security header toe.
2. MET HTTPS-omleidings-middleware (UseHttpsRedirection) worden HTTP-aanvragen omgeleid naar HTTPS.
3. Middleware voor statische bestanden (UseStaticFiles) geeft statische bestanden terug en voorkomt verdere aanvraagverwerking.
4. Cookie beleidsmiddleware (UseCookiePolicy) brengt de app in overeenstemming met de AVG-regelgeving van de EU.
5. Routeringsmiddleware (UseRouting) om verzoeken te routeren.
6. Verificatie-middleware (UseAuthentication) probeert de gebruiker te verifiëren voordat ze toegang krijgen tot beveiligde resources.
7. Met autorisatie-middleware (UseAuthorization) kan een gebruiker toegang krijgen tot beveiligde resources.
8. Sessie-middleware (UseSession) brengt de sessiestatus tot stand en onderhoudt deze. Als de app de sessiestatus gebruikt, roept u sessie-middleware aan na cookie beleids-middleware en vóór MVC-middleware.
9. Middleware voor eindpuntroutering (UseEndpoints met MapRazorPages) om Razor Pages-eindpunten toe te voegen aan de aanvraagverwerkingspipeline.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseDatabaseErrorPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();
    app.UseCookiePolicy();
    app.UseRouting();
    app.UseAuthentication();
    app.UseAuthorization();
    app.UseSession();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

In de voorgaande voorbeeldcode wordt elke middleware-extensiemethode weergegeven op IApplicationBuilder via de Microsoft.AspNetCore.Builder naamruimte.

UseExceptionHandler is het eerste middlewareonderdeel dat aan de pijplijn is toegevoegd. Daarom vangt de middleware voor uitzonderingsafhandeling eventuele uitzonderingen op die optreden in latere aanroepen.

Middleware voor statische bestanden wordt vroeg in de pijplijn aangeroepen, zodat deze verzoeken kan afhandelen en de verwerking kan afbreken zonder door de overige componenten te gaan. De statische bestands-middleware biedt geen autorisatiecontroles. Alle bestanden die worden geleverd door statische bestands-middleware, inclusief bestanden onder wwwroot, zijn openbaar beschikbaar. Zie Statische bestanden serveren in ASP.NET Core Apps voor een benadering voor het beveiligen van statische bestanden.

Als de aanvraag niet wordt verwerkt door de statische bestands-middleware, wordt deze doorgegeven aan de verificatie-middleware (UseAuthentication), waarmee verificatie wordt uitgevoerd. Authenticatie omzeilt geen niet-geauthenticeerde verzoeken. Hoewel verificatie-middleware aanvragen verifieert, vindt autorisatie (en afwijzing) alleen plaats nadat MVC een specifieke Razor pagina of MVC-controller en -actie heeft geselecteerd.

In het volgende voorbeeld ziet u een middlewarevolgorde waarin aanvragen voor statische bestanden worden verwerkt door statische bestands-middleware voordat middleware voor reactiecompressie wordt verwerkt. Statische bestanden worden niet gecomprimeerd met deze middlewarevolgorde. De reacties van de Razor-pagina kunnen worden gecomprimeerd.

public void Configure(IApplicationBuilder app)
{
    // Static files aren't compressed by static file middleware.
    app.UseStaticFiles();

    app.UseRouting();

    app.UseResponseCompression();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

Voor SPA's (Single Page Applications) komt de spa-middleware UseSpaStaticFiles meestal de laatste in de middleware-pijplijn. De spa middleware komt als laatste:

• Om alle andere middleware eerst te laten reageren op overeenkomende aanvragen.
• Om SPA's met client-side-routering te laten werken voor alle routes die de servertoepassing niet herkent.

Zie de handleidingen voor de projectsjablonen React en Angular voor meer informatie over SPA's.