ASP.NET Core-mellanprogram

Skapa en pipeline för mellanprogram med WebApplication

Pipelinen för ASP.NET Core-begäran består av en sekvens med förfrågedelegater som anropas efter varandra. Följande diagram visar konceptet. Exekveringstråden följer de svarta pilarna.

Varje ombud kan utföra åtgärder före och efter nästa ombud. Ombud för undantagshantering bör anropas tidigt i pipelinen, så att de kan fånga upp undantag som inträffar i senare skeden av pipelinen.

Det enklaste sättet att anropa en ASP.NET Core-app Run är att ställa in en enda terminal mellanvara som en anonym funktionsbegäran, vilket möjliggör hantering av begäran utan någon förfrågningspipeline.

I följande exempel:

• Anropet till RunExtensions.Run anropas på varje begäran och skriver "Hello world!" till svaret.
• Anropet till WebApplication.Run i slutet av kodblocket kör appen och blockerar den anropande tråden tills värden stängs av.

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

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

app.Run();

Svar vid åtkomst till appen i en webbläsare vid dess start-URL:

Hello world!

Länka flera ombud för förfrågningar tillsammans med Use. Parametern next representerar nästa ombud i pipelinen. Du kan utföra åtgärder vanligtvis både före och efter delegeringen next.

Följande exempel visar:

• Två Use anrop, var och en skriver till konsolen:
  • Där arbete kan utföras som kan skriva till svaret (context.Response, HttpResponse).
  • Där arbete kan utföras utan att skriva till svaret efter att parametern next har anropats.
• Ett ombud för terminalbegäran med ett anrop till RunExtensions.Run som skriver "Hello world!" till svaret.
• Ett sista Use anrop som aldrig körs eftersom det följer terminalbegärandelegeringen Run .
• Ett anrop till WebApplication.Run i slutet av kodblocket för att köra appen och blockera den anropande tråden tills värden stängs av.

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();

I appens konsolfönster när appen körs:

Arbete som kan skriva till svaret. (1)
Arbete som kan skriva till svaret. (2)
Arbete som inte skriver till svaret. (2)
Arbete som inte skriver till svaret. (1)

Det är ofta önskvärt att kortsluta pipelinen för begäran eftersom den undviker onödigt arbete. Till exempel kan statiska filmellanprogram fungera som ett terminalmellanprogram genom att bearbeta en begäran om en statisk fil och kortsluta resten av pipelinen. Mellanprogramvara som läggs till i pipelinen före terminalmellanprogramvaran bearbetar fortfarande kod efter sina next.Invoke instruktioner. Om du inte planerar att anropa next.Invoke eftersom ditt mål är att avsluta pipelinen, använd en Run delegat istället för att anropa Use-tilläggsmetoden.

Anropa next.Invoke inte under eller efter att svaret har skickats till klienten. När en HttpResponse har startats resulterar ändringar i ett undantag. Om du till exempel anger rubriker eller en svarsstatuskod utlöser du ett undantag när svaret har startats. Att skriva till svarstexten efter anropet next kan:

• Orsaka en protokollöverträdelse, till exempel att skriva fler byte till svaret än det angivna svarets innehållslängd (Content-Length rubrikvärde).
• Skada brödtextformatet, till exempel att skriva en HTML-sidfot till en CSS-fil.

För att avgöra om svaret har startat kontrollerar du värdet för HasStarted.

Mer information finns i Kortslutning mellanprogram efter routning.

Run Delegera

En Run delegerad tar inte emot en next parameter. Det första Run delegerade avslutar alltid pipelinen. Run är också en konvention, och vissa mellanprogram kan exponera Run metoder som körs i slutet av pipelinen.

Inga Use eller Run delegater anropas efter att den första Run delegaten anropats.

Förgrena pipelinen för mellanprogram

Map tillägg används som en konvention för att förgrena pipelinen för bearbetning av begäranden. Map förgrenar pipelinen för begäran baserat på matchningar av den angivna sökvägen för begäran. Om begärandesökvägen börjar med den angivna sökvägen körs grenen.

I följande exempel HandleMap1 anropas för begäranden till /map1och HandleMap2 anropas för begäranden till /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");
    });
}

I följande tabell visas begäranden och svar med hjälp av föregående kod.

När Map används tas de matchade sökvägssegmenten bort från HttpRequest.Path och läggs till i HttpRequest.PathBase för varje begäran.

Map kan matcha flera segment samtidigt:

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'");
    });
}

I följande tabell visas begäranden och svar med hjälp av föregående kod.

Map stöder kapsling:

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();

I följande tabell visas begäranden och svar med hjälp av föregående kod.

MapWhen förgrenar pipelinen för begäran baserat på resultatet av det angivna predikatet. Alla predikat av typen Func<HttpContext, bool> kan användas för att mappa begäranden till en ny gren av pipelinen. I följande exempel används ett predikat för att identifiera förekomsten av en frågesträngsvariabel med namnet "branch":

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}'");
    });
}

I följande tabell visas begäranden och svar med hjälp av föregående kod.

UseWhen kan förgrena pipelinen för begäran baserat på resultatet av det angivna predikatet. Till skillnad från MapWhenåteransluts grenen till huvudpipelinen om den inte innehåller något terminalmellanprogram:

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.");
    });
}

I föregående exempel skrivs ett svar av "Hello from the non-Map delegate." för alla begäranden. Om begäran innehåller en frågesträngsvariabel med namnet "branch" loggas dess värde innan huvudpipelinen återansluts.

Skapa en pipeline för mellanprogram med IApplicationBuilder

Pipelinen för ASP.NET Core-begäran består av en sekvens med förfrågedelegater som anropas efter varandra. Följande diagram visar konceptet. Exekveringstråden följer de svarta pilarna.

Varje ombud kan utföra åtgärder före och efter nästa ombud. Ombud för undantagshantering bör anropas tidigt i pipelinen, så att de kan fånga upp undantag som inträffar i senare skeden av pipelinen.

Den enklaste möjliga ASP.NET Core-appen konfigurerar ett ombud för en enda begäran som hanterar alla begäranden. Det här fallet innehåller inte en verklig begärandepipeline. I stället anropas en enda anonym funktion som svar på varje HTTP-begäran.

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

Länka flera ombud för förfrågningar tillsammans med Use. Parametern next representerar nästa ombud i pipelinen. Du kan kortsluta pipelinen genom att inte anropa parametern nästa. Du kan vanligtvis utföra åtgärder både före och efter nästa ombud, vilket visas i följande exempel:

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.
});

När en delegerad inte vidarebefordrar en begäran till nästa delegerad kallas det att avbryta begärandepipelinen. Kortslutning är ofta önskvärt eftersom det undviker onödigt arbete. Till exempel kan statiska filmellanprogram fungera som ett terminalmellanprogram genom att bearbeta en begäran om en statisk fil och kortsluta resten av pipelinen. Mellanprogram som lagts till i pipelinen innan mellanprogrammet som avslutar ytterligare bearbetning bearbetar fortfarande kod efter deras next.Invoke-instruktioner. Se dock följande varning om att försöka skriva till ett svar som redan har skickats.

Run ombud får ingen next parameter. Den första Run delegerade är alltid terminal och avslutar pipelinen. Run är en konvention. Vissa mellanprogramskomponenter kan exponera Run[Middleware] metoder som körs i slutet av pipelinen:

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

I föregående exempel skriver Run-ombudet "Hello from 2nd delegate." till svaret och avslutar sedan pipelinen. Om en annan Use- eller Run-ombud läggs till efter Run-ombudet, så anropas det inte.

Förgrena pipelinen för mellanprogram

Map tillägg används som en konvention för att förgrena pipelinen. Map förgrenar pipelinen för begäran baserat på matchningar av den angivna sökvägen för begäran. Om begärandesökvägen börjar med den angivna sökvägen körs grenen.

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.");
        });
    }
}

I följande tabell visas begäranden och svar från http://localhost:1234 med hjälp av föregående kod.

När Map används tas de matchade sökvägssegmenten bort från HttpRequest.Path och läggs till i HttpRequest.PathBase för varje begäran.

Map stöder kapsling, till exempel:

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

Map kan också matcha flera segment samtidigt:

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 förgrenar pipelinen för begäran baserat på resultatet av det angivna predikatet. Du kan använda valfritt predikat av typen Func<HttpContext, bool> för att mappa begäranden till en ny gren av pipelinen. I följande exempel identifierar ett predikat förekomsten av en frågesträngsvariabel 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.");
        });
    }
}

I följande tabell visas begäranden och svar från http://localhost:1234 med hjälp av föregående kod.

UseWhen förgrenar även pipelinen för begäran baserat på resultatet av det angivna predikatet. Till skillnad från med MapWhenåteransluts den här grenen till huvudpipelinen om den inte kortsluter eller innehåller ett terminalmellanprogram:

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.");
        });
    }
}

I det föregående exemplet skrivs svaret "Hej från huvudröret" för alla begäranden. Om begäran innehåller en frågesträngsvariabel branchloggas dess värde innan huvudpipelinen återansluts.

Mellanprogram läggs till automatiskt av 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;
});

Ordningen som mellanmjukvaror visas i appens Program-filen anger ordningen i vilken de anropas vid en begäran, med omvänd ordning för svaret.

Du har fullständig kontroll över ordningen på mellanprogram och möjligheten att lägga till anpassade mellanprogram för scenarier för bearbetning av begäranden, med tanke på att ordningen på mellanprogram kan vara avgörande för säkerhet, prestanda och funktioner.

I följande exempel visas mellanprogramsordning för vanliga appscenarier. Varje mellanprogramstilläggsmetod exponeras på WebApplicationBuilder genom Microsoft.AspNetCore.Builder-namnområdet.

1. Undantags- och felhantering
   • När appen körs i Development miljön:
     • Mellanprogrammet för felsidan för utvecklare (UseDeveloperExceptionPage) rapporterar körningsfel i appen.
     • Databasfelsidans mellanprogram (UseDatabaseErrorPage) rapporterar databaskörningsfel.
   • När appen körs i Production miljön:
     • Undantagshanterarens mellanprogram (UseExceptionHandler) fångar undantag som genereras i följande mellanprogram.
     • HTTP Strict Transport Security (HSTS)-protokollmellanprogram (UseHsts) lägger till huvudet Strict-Transport-Security.
2. HTTPS-omdirigeringsmellanprogram (UseHttpsRedirection) omdirigerar HTTP-begäranden till HTTPS.
3. Middleware för statiska filer (om det behövs, UseStaticFiles) returnerar statiska filer och avbryter vidare bearbetning av begäran.
4. Cookie policy-mellanprogram (UseCookiePolicy) anpassar appen till EU:s allmänna dataskyddsförordning (GDPR).
5. Dirigera mellanprogram (UseRouting) till routningsbegäranden.
6. Mellanprogram för autentisering (UseAuthentication) försöker autentisera användaren innan de får åtkomst till säkra resurser.
7. Auktorisering mellanprogram (UseAuthorization) ger en användare åtkomst till säkra resurser.
8. Förfalskningsskyddsmellanprogram (UseAntiforgery) lägger till förfalskningsskyddsmellanprogram i pipelineflödet UseAntiforgery måste placeras efter anrop till UseAuthentication och UseAuthorization.
9. Sessionsmellanprogramvara (Razor gäller endast Pages och MVC, UseSession) etablerar och upprätthåller sessionstillstånd. Om appen använder sessionstillstånd anropar du sessionsmellanprogram efter cookie principmellanprogram och före Razor Pages/MVC-mellanprogram.
10. Mellanprogram för slutpunktsroutning

• MapRazorComponents för att lägga till Razor komponentslutpunkter i begärandepipelinen.
• MapRazorPages för att lägga till Razor sidslutpunkter i pipelinen för begäran.
• MapControllerRoute för att lägga till kontrollantslutpunkter i pipelinen för begäran.

Typisk Blazor Web App pipeline för mellanprogram:

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();

Typisk 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();

I föregående kod:

• CORS-mellanprogram (UseCors), mellanprogram för autentisering (UseAuthentication) och mellanprogram för auktorisering (UseAuthorization) måste visas i den ordning som visas.
• CORS-mellanprogram (UseCors) måste komma före mellanprogrammet för svarscachelagring (UseResponseCaching) för att lägga till CORS-huvuden för varje begäran, inklusive cachelagrade svar. Mer information finns i Det är inte klart att UseCORS måste komma före UseResponseCaching (dotnet/aspnetcore #23218.
• Middleware för lokalisering av begäran (UseRequestLocalization) måste komma före all middleware som kan kontrollera begärans kultur, till exempel middleware för statiska filer (UseStaticFiles).
• Frekvensbegränsande mellanprogram (UseRateLimiter) måste anropas efter routning av mellanprogram (UseRouting) när hastighetsbegränsning av slutpunktsspecifika API:er används. Om [EnableRateLimiting] attributet till exempel används måste hastighetsbegränsande mellanprogram anropas efter routning av mellanprogram. När du endast anropar globala gränsbegränsare kan hastighetsbegränsande mellanprogram anropas innan mellanprogram dirigeras.

I vissa scenarier har mellanprogram olika sortering. Cachelagring och komprimeringsordning beror till exempel på appens specifikation. I följande ordning kan CPU-användningen minskas genom cachelagring av det komprimerade svaret, men appen kan i slutändan cachelagra flera representationer av en resurs med olika komprimeringsalgoritmer, till exempel Gzip eller Brotli:

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

Statiska tillgångar hanteras vanligtvis tidigt i pipelinen så att appen kan kortsluta bearbetning av begäranden för att förbättra prestandan.

Autentisering kortsluter inte oautentiserade begäranden. Även om autentiseringsmiddleware autentiserar begäranden, sker auktorisering efter att ramverket väljer en Razor-komponent i en Blazor Web App, en sida i en Razor Pages-app eller en styrenhet och åtgärd i en MVC-app.

Följande diagram visar den fullständiga pipelinen för bearbetning av begäranden för ASP.NET Core MVC- och Razor Pages-appar. Du kan se hur befintliga mellanprogram sorteras i en typisk app och var anpassade mellanprogram läggs till. Du har fullständig kontroll över hur du ändrar ordning på befintliga mellanprogram eller matar in nya anpassade mellanprogram efter behov för dina scenarier.

Endpoint-middleware i föregående diagram kör filterpipelinen för motsvarande apptyp – MVC eller Razor Pages.

Föregående diagram visar mellanprogrammet Routning efter statiska filer. Den här ordningen är hur projektmallarna fungerar genom att uttryckligen anropa appen. UseRouting. Om du inte anropar app.UseRoutingkörs Routning mellanprogram i början av pipelinen som standard. För mer information, se Routing.

I den ordning du lägger till mellanprogramskomponenter i Program.cs filen definieras i vilken ordning mellanprogramkomponenterna anropas på begäranden och omvänd ordning för svaret. Ordningen är kritisk för säkerhet, prestanda och funktioner.

Följande markerade kod i Program.cs lägger till säkerhetsrelaterade mellanprogramskomponenter i den vanliga rekommenderade ordningen:

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();

I föregående kod:

• Kommenterade mellanprogram läggs inte till när du skapar en ny webbapp med enskilda användarkonton.
• Inte alla mellanprogram visas i den här exakta ordningen, men många gör det. Till exempel:
  • UseCors, UseAuthenticationoch UseAuthorization måste visas i den ordning som visas.
  • UseCors måste för närvarande visas innan UseResponseCaching. Det här kravet förklaras i GitHub-problem med dotnet/aspnetcore #23218.
  • UseRequestLocalization måste visas före alla mellanprogram som kan kontrollera begärandekulturen, till exempel app.UseStaticFiles().
  • UseRateLimiter måste anropas efter UseRouting när hastighetsbegränsning av slutpunktsspecifika API:er används. Om attributet [EnableRateLimiting] till exempel används måste UseRateLimiter anropas efter UseRouting. När du bara anropar globala begränsare kan UseRateLimiter anropas innan UseRouting.

I vissa scenarier har mellanprogram olika sortering. Cachelagring och komprimeringsordning är till exempel scenariospecifika, och det finns flera giltiga ordningar. Till exempel:

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

Med föregående kod kan du minska CPU-användningen genom att cachelagra det komprimerade svaret, men det kan sluta med att du cachelagrar flera representationer av en resurs med olika komprimeringsalgoritmer som Gzip eller Brotli.

Följande ordning kombinerar statiska filer för att tillåta cachelagring av komprimerade statiska filer:

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

Följande Program.cs kod lägger till mellanprogramskomponenter för vanliga appscenarier:

1. Undantags- och felhantering
   • När appen körs i Development miljön:
     • Mellanprogrammet för felsidan för utvecklare (UseDeveloperExceptionPage) rapporterar körningsfel i appen.
     • Databasfelsidans mellanprogram (UseDatabaseErrorPage) rapporterar databaskörningsfel.
   • När appen körs i Production miljön:
     • Undantagshanterarens mellanprogram (UseExceptionHandler) fångar undantag som genereras i följande mellanprogram.
     • HTTP Strict Transport Security (HSTS)-protokollmellanprogram (UseHsts) lägger till huvudet Strict-Transport-Security.
2. HTTPS-omdirigeringsmellanprogram (UseHttpsRedirection) omdirigerar HTTP-begäranden till HTTPS.
3. Middleware för statiska filer (UseStaticFiles) levererar statiska filer och avbryter vidare bearbetning av begäran.
4. Cookie policy-mellanprogramvara (UseCookiePolicy) anpassar appen till EU:s allmänna dataskyddsförordning (GDPR).
5. Dirigera mellanprogram (UseRouting) till routningsbegäranden.
6. Mellanprogram för autentisering (UseAuthentication) försöker autentisera användaren innan de får åtkomst till säkra resurser.
7. Auktorisering mellanprogram (UseAuthorization) ger en användare åtkomst till säkra resurser.
8. Sessionsmellanprogram (UseSession) upprättar och underhåller sessionstillstånd. Om appen använder sessionstillstånd, anropar du sessionsmellanprogrammet efter cookie-principmellanprogrammet och före MVC-mellanprogrammet.
9. Mellanprogram för slutpunktsdirigering (UseEndpoints med MapRazorPages) för att lägga till slutpunkter för Razor Pages i begärandepipelinen.

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();

I föregående exempelkod exponeras varje middleware-metod på WebApplicationBuilder genom Microsoft.AspNetCore.Builder-namnrymden.

UseExceptionHandler är den första mellanprogramskomponenten som läggs till i pipelinen. Därför fångar undantagshanterarens mellanprogram alla undantag som inträffar i senare anrop.

Mellanprogram för statiska filer anropas tidigt i pipelinen så att det kan hantera begäranden och kortslutning utan att gå igenom de återstående komponenterna. Mellanprogrammet för statiska filer utför inga auktoriseringskontroller. Alla filer som hanteras av statiska filmellanprogram, inklusive de under wwwroot, är offentligt tillgängliga. En metod för att skydda statiska filer finns i Hantera statiska filer i ASP.NET Core-appar.

Om begäran inte hanteras av den statiska filmellanprogrammet skickas den vidare till mellanprogrammet för autentisering (UseAuthentication), som utför autentisering. Autentisering kortsluter inte oautentiserade begäranden. Även om autentisering mellanprogram autentiserar begäranden sker auktorisering (och avvisande) först efter att MVC har valt en specifik Razor sida eller MVC-kontrollant och åtgärd.

I följande exempel visas en mellanprogramsordning där begäranden om statiska filer hanteras av statiska filmellanprogram före mellanprogram för svarskomprimering. Statiska filer komprimeras inte med den här mellanprogramsordningen. Svar på sidor Razor kan komprimeras.

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

app.UseRouting();

app.UseResponseCompression();

app.MapRazorPages();

Följande diagram visar den fullständiga pipelinen för bearbetning av begäranden för ASP.NET Core MVC- och Razor Pages-appar. Du kan se hur befintliga mellanprogram sorteras i en typisk app och var anpassade mellanprogram läggs till. Du har fullständig kontroll över hur du ändrar ordning på befintliga mellanprogram eller matar in nya anpassade mellanprogram efter behov för dina scenarier.

Endpoint-middleware i föregående diagram kör filterpipelinen för motsvarande apptyp – MVC eller Razor Pages.

Föregående diagram visar mellanprogrammet Routning efter statiska filer. Den här ordningen är hur projektmallarna fungerar genom att uttryckligen anropa appen. UseRouting. Om du inte anropar app.UseRoutingkörs Routning mellanprogram i början av pipelinen som standard. För mer information, se Routing.

I den ordning du lägger till mellanprogramskomponenter i Program.cs filen definieras i vilken ordning mellanprogramkomponenterna anropas på begäranden och omvänd ordning för svaret. Ordningen är kritisk för säkerhet, prestanda och funktioner.

Följande markerade kod i Program.cs lägger till säkerhetsrelaterade mellanprogramskomponenter i den vanliga rekommenderade ordningen:

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();

I föregående kod:

• Kommenterade mellanprogram läggs inte till när du skapar en ny webbapp med enskilda användarkonton.
• Inte alla mellanprogram visas i den här exakta ordningen, men många gör det. Till exempel:
  • UseCors, UseAuthenticationoch UseAuthorization måste visas i den ordning som visas.
  • UseCors måste för närvarande visas innan UseResponseCaching. Det här kravet förklaras i GitHub-problem med dotnet/aspnetcore #23218.
  • UseRequestLocalization måste visas före alla mellanprogram som kan kontrollera begärandekulturen (till exempel app.UseMvcWithDefaultRoute()).

I vissa scenarier har mellanprogram olika sortering. Cachelagring och komprimeringsordning är till exempel scenariospecifika, och det finns flera giltiga ordningar. Till exempel:

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

Med föregående kod kan du minska CPU-användningen genom att cachelagra det komprimerade svaret, men det kan sluta med att du cachelagrar flera representationer av en resurs med olika komprimeringsalgoritmer som Gzip eller Brotli.

Följande ordning kombinerar statiska filer för att tillåta cachelagring av komprimerade statiska filer:

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

Följande Program.cs kod lägger till mellanprogramskomponenter för vanliga appscenarier:

1. Undantags- och felhantering
   • När appen körs i Development miljön:
     • Mellanprogrammet för felsidan för utvecklare (UseDeveloperExceptionPage) rapporterar körningsfel i appen.
     • Databasfelsidans mellanprogram (UseDatabaseErrorPage) rapporterar databaskörningsfel.
   • När appen körs i Production miljön:
     • Undantagshanterarens mellanprogram (UseExceptionHandler) fångar undantag som genereras i följande mellanprogram.
     • HTTP Strict Transport Security (HSTS)-protokollmellanprogram (UseHsts) lägger till huvudet Strict-Transport-Security.
2. HTTPS-omdirigeringsmellanprogram (UseHttpsRedirection) omdirigerar HTTP-begäranden till HTTPS.
3. Middleware för statiska filer (UseStaticFiles) levererar statiska filer och avbryter vidare bearbetning av begäran.
4. Cookie policy-mellanprogramvara (UseCookiePolicy) anpassar appen till EU:s allmänna dataskyddsförordning (GDPR).
5. Dirigera mellanprogram (UseRouting) till routningsbegäranden.
6. Mellanprogram för autentisering (UseAuthentication) försöker autentisera användaren innan de får åtkomst till säkra resurser.
7. Auktorisering mellanprogram (UseAuthorization) ger en användare åtkomst till säkra resurser.
8. Sessionsmellanprogram (UseSession) upprättar och underhåller sessionstillstånd. Om appen använder sessionstillstånd, anropar du sessionsmellanprogrammet efter cookie-principmellanprogrammet och före MVC-mellanprogrammet.
9. Mellanprogram för slutpunktsdirigering (UseEndpoints med MapRazorPages) för att lägga till slutpunkter för Razor Pages i begärandepipelinen.

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();

I föregående exempelkod exponeras varje middleware-metod på WebApplicationBuilder genom Microsoft.AspNetCore.Builder-namnrymden.

UseExceptionHandler är den första mellanprogramskomponenten som läggs till i pipelinen. Därför fångar undantagshanterarens mellanprogram alla undantag som inträffar i senare anrop.

Mellanprogram för statiska filer anropas tidigt i pipelinen så att det kan hantera begäranden och kortslutning utan att gå igenom de återstående komponenterna. Mellanprogrammet för statiska filer utför inga auktoriseringskontroller. Alla filer som hanteras av statiska filmellanprogram, inklusive de under wwwroot, är offentligt tillgängliga. En metod för att skydda statiska filer finns i Hantera statiska filer i ASP.NET Core-appar.

Om begäran inte hanteras av den statiska filmellanprogrammet skickas den vidare till mellanprogrammet för autentisering (UseAuthentication), som utför autentisering. Autentisering kortsluter inte oautentiserade begäranden. Även om autentisering mellanprogram autentiserar begäranden sker auktorisering (och avvisande) först efter att MVC har valt en specifik Razor sida eller MVC-kontrollant och åtgärd.

I följande exempel visas en mellanprogramsordning där begäranden om statiska filer hanteras av statiska filmellanprogram före mellanprogram för svarskomprimering. Statiska filer komprimeras inte med den här mellanprogramsordningen. Svar på sidor Razor kan komprimeras.

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

app.UseRouting();

app.UseResponseCompression();

app.MapRazorPages();

Följande diagram visar den fullständiga pipelinen för bearbetning av begäranden för ASP.NET Core MVC- och Razor Pages-appar. Du kan se hur befintliga mellanprogram sorteras i en typisk app och var anpassade mellanprogram läggs till. Du har fullständig kontroll över hur du ändrar ordning på befintliga mellanprogram eller matar in nya anpassade mellanprogram efter behov för dina scenarier.

Endpoint-middleware i föregående diagram kör filterpipelinen för motsvarande apptyp – MVC eller Razor Pages.

Ordningen som mellanprogramkomponenter läggs till i metoden Startup.Configure definierar i vilken ordning mellanprogramkomponenterna anropas på begäranden och omvänd ordning för svaret. Ordningen är kritisk för säkerhet, prestanda och funktioner.

Följande Startup.Configure-metod lägger till säkerhetsrelaterade mellanprogramskomponenter i den vanliga rekommenderade ordningen:

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?}");
    });
}

I föregående kod:

• Kommenterade mellanprogram läggs inte till när du skapar en ny webbapp med enskilda användarkonton.
• Inte alla mellanprogram visas i den här exakta ordningen, men många gör det. Till exempel:
  • UseCors, UseAuthenticationoch UseAuthorization måste visas i den ordning som visas.
  • UseCors måste för närvarande visas innan UseResponseCaching på grund av detta fel .
  • UseRequestLocalization måste visas före alla mellanprogram som kan kontrollera begärandekulturen (till exempel app.UseMvcWithDefaultRoute()).

I vissa scenarier har mellanprogram olika sortering. Cachelagring och komprimeringsordning är till exempel scenariospecifika och det finns flera giltiga ordningar. Till exempel:

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

Med föregående kod kan CPU sparas genom att cachelagra det komprimerade svaret, men det kan sluta med att du cachelagrar flera representationer av en resurs med olika komprimeringsalgoritmer som Gzip eller Brotli.

Följande ordning kombinerar statiska filer för att tillåta cachelagring av komprimerade statiska filer:

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

Följande Startup.Configure-metod lägger till mellanprogramskomponenter för vanliga appscenarier:

1. Undantags- och felhantering
   • När appen körs i Development miljön:
     • Mellanprogrammet för felsidan för utvecklare (UseDeveloperExceptionPage) rapporterar körningsfel i appen.
     • Databasfelsidans mellanprogram rapporterar databaskörningsfel.
   • När appen körs i Production miljön:
     • Undantagshanterarens mellanprogram (UseExceptionHandler) fångar undantag som genereras i följande mellanprogram.
     • HTTP Strict Transport Security (HSTS)-protokollmellanprogram (UseHsts) lägger till huvudet Strict-Transport-Security.
2. HTTPS-omdirigeringsmellanprogram (UseHttpsRedirection) omdirigerar HTTP-begäranden till HTTPS.
3. Middleware för statiska filer (UseStaticFiles) levererar statiska filer och avbryter vidare bearbetning av begäran.
4. Cookie policy-mellanprogramvara (UseCookiePolicy) anpassar appen till EU:s allmänna dataskyddsförordning (GDPR).
5. Dirigera mellanprogram (UseRouting) till routningsbegäranden.
6. Mellanprogram för autentisering (UseAuthentication) försöker autentisera användaren innan de får åtkomst till säkra resurser.
7. Auktorisering mellanprogram (UseAuthorization) ger en användare åtkomst till säkra resurser.
8. Sessionsmellanprogram (UseSession) upprättar och underhåller sessionstillstånd. Om appen använder sessionstillstånd, anropar du sessionsmellanprogrammet efter cookie-principmellanprogrammet och före MVC-mellanprogrammet.
9. Mellanprogram för slutpunktsdirigering (UseEndpoints med MapRazorPages) för att lägga till slutpunkter för Razor Pages i begärandepipelinen.

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();
    });
}

I föregående exempelkod exponeras varje middleware-metod på IApplicationBuilder genom Microsoft.AspNetCore.Builder-namnrymden.

UseExceptionHandler är den första mellanprogramskomponenten som läggs till i pipelinen. Därför fångar undantagshanterarens mellanprogram alla undantag som inträffar i senare anrop.

Mellanprogram för statiska filer anropas tidigt i pipelinen så att det kan hantera begäranden och kortslutning utan att gå igenom de återstående komponenterna. Mellanprogrammet för statiska filer utför inga auktoriseringskontroller. Alla filer som hanteras av statiska filmellanprogram, inklusive de under wwwroot, är offentligt tillgängliga. En metod för att skydda statiska filer finns i Hantera statiska filer i ASP.NET Core-appar.

Om begäran inte hanteras av den statiska filmellanprogrammet skickas den vidare till mellanprogrammet för autentisering (UseAuthentication), som utför autentisering. Autentisering kortsluter inte oautentiserade begäranden. Även om autentisering mellanprogram autentiserar begäranden sker auktorisering (och avvisande) först efter att MVC har valt en specifik Razor sida eller MVC-kontrollant och åtgärd.

I följande exempel visas en mellanprogramsordning där begäranden om statiska filer hanteras av statiska filmellanprogram före mellanprogram för svarskomprimering. Statiska filer komprimeras inte med den här mellanprogramsordningen. Svar på sidor Razor kan komprimeras.

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();
    });
}

För ensidesprogram (SPA) kommer SPA-mellanprogrammet UseSpaStaticFiles vanligtvis sist i pipelinen för mellanprogram. SPA-mellanprogrammet kommer sist:

• För att alla andra mellanprogram ska kunna svara på matchande begäranden först.
• För att tillåta att SPA:er med routning på klientsidan körs för alla vägar som serverappen inte känner igen.

Mer information om SPA finns i guiderna för projektmallarna React och Angular.