Cookie Anmeldeumleitungen sind für bekannte API-Endpunkte deaktiviert.

Standardmäßig führen nicht authentifizierte und nicht autorisierte Anforderungen an bekannte API-Endpunkte, die durch cookie die Authentifizierung geschützt sind, jetzt zu 401- und 403-Antworten, anstatt zu einem Anmelde- oder Zugriffsverweigerungs-URI umzuleiten.

Bekannte API-Endpunkte werden mithilfe der neuen IDisableCookieRedirectMetadata Schnittstelle identifiziert, und Metadaten, die die neue Schnittstelle implementieren, wurden automatisch zu den folgenden Hinzugefügt:

  • [ApiController] Endpunkte.
  • Minimale API-Endpunkte, die JSON-Anforderungstexte lesen oder JSON-Antworten schreiben.
  • Endpunkte, die TypedResults Rückgabetypen verwenden.
  • SignalR Endpunkte.

Die zugehörige Schnittstelle IAllowCookieRedirectMetadata aktiviert für einen Endpunkt die Weiterleitung wieder. Es überschreibt IDisableCookieRedirectMetadata unabhängig von der Reihenfolge, in der die Metadaten hinzugefügt werden.

Die Antworten 401 und 403 enthalten weiterhin eine Location Kopfzeile, die den Anmelde- oder Zugriffsverweigerungs-URI enthält. Nur der Statuscode ändert sich.

Nur die Challengepfade (401) und Verweigernpfade (403) berücksichtigen Endpunkt-Metadaten. Abmelde- und Rückgabe-URL-Umleitungen sind nicht betroffen.

Eingeführt in Version

.NET 10 Preview 7

Vorheriges Verhalten

Zuvor hat der cookie Authentifizierungshandler nicht authentifizierte und nicht autorisierte Anforderungen standardmäßig für alle Anforderungen außer XMLHttpRequests (XHRs) an einen Anmelde- oder Zugriffsverweigerungs-URI umgeleitet.

Neues Verhalten

Ab .NET 10 führen nicht authentifizierte und nicht autorisierte Anforderungen an bekannte API-Endpunkte zu 401- und 403-Antworten, anstatt zu einem Anmelde- oder Zugriffsverweigerungs-URI umzuleiten. XHRs führen unabhängig vom Zielendpunkt weiterhin zu 401- und 403-Antworten.

Art der einschneidenden Änderung

Diese Änderung ist eine Verhaltensänderung.

Grund für Änderung

Diese Änderung wurde dringend angefordert. Das Umleiten nicht authentifizierter Anforderungen an eine Anmeldeseite ist in der Regel nicht sinnvoll für API-Endpunkte, die in der Regel auf 401- und 403-Statuscodes basieren, anstatt HTML-Umleitungen, um Authentifizierungsfehler zu kommunizieren.

Um das vorherige Verhalten für die gesamte App wiederherzustellen, aktivieren Sie den Microsoft.AspNetCore.Authentication.Cookies.IgnoreRedirectMetadata Schalter. CookieAuthentifizierung ignoriert dann Endpunktmetadaten, und nur XHRs führen zu 401- und 403-Antworten, die dem Verhalten vor .NET 10 entsprechen. Legen Sie den Switch in der Projektdatei so fest, dass er angewendet wird, bevor app-Code ausgeführt wird:

<ItemGroup>
  <RuntimeHostConfigurationOption
    Include="Microsoft.AspNetCore.Authentication.Cookies.IgnoreRedirectMetadata"
    Value="true" />
</ItemGroup>

Der Schalter wird einmalig ausgelesen, und zwar bei der ersten Verwendung der Authentifizierung cookie; wenn Sie ihn stattdessen im Code festlegen, rufen Sie SetSwitch auf, bevor der Host erstellt wird:

AppContext.SetSwitch(
    "Microsoft.AspNetCore.Authentication.Cookies.IgnoreRedirectMetadata", true);

var builder = WebApplication.CreateBuilder(args);

Umleitungen für einzelne Endpunkte stattdessen wiederherzustellen, rufen Sie AllowCookieRedirect auf, oder wenden Sie AllowCookieRedirectAttribute auf eine Aktionsmethode oder eine Controllerklasse an:

app.MapGet("/reports/summary", () => new { Total = 1000 })
   .RequireAuthorization()
   .AllowCookieRedirect();

Umgekehrt rufen Sie DisableCookieRedirect auf, um 401- und 403-Statuscodes für Endpunkte zurückzugeben, die nicht automatisch als API-Endpunkte erkannt werden.

Wenn Sie bei nicht authentifizierten oder nicht autorisierten Anforderungen immer zu den Anmelde- und Zugriffsverweigerungs-URIs umleiten möchten, unabhängig davon, ob das Ziel ein spezifischer Endpunkt ist oder die Quelle der Anforderung ein XHR, können Sie Folgendes überschreiben: RedirectToLoginRedirectToAccessDenied

builder.Services.AddAuthentication()
    .AddCookie(options =>
    {
        options.Events.OnRedirectToLogin = context =>
        {
            context.Response.Redirect(context.RedirectUri);
            return Task.CompletedTask;
        };

        options.Events.OnRedirectToAccessDenied = context =>
        {
            context.Response.Redirect(context.RedirectUri);
            return Task.CompletedTask;
        };
    });

Wenn Sie das genaue vorherige Verhalten wiederherstellen möchten, das die Umleitung nur für XHRs verhindert, können Sie die Ereignisse mit dieser etwas komplizierteren Logik außer Kraft setzen:

builder.Services.AddAuthentication()
    .AddCookie(options =>
    {
        bool IsXhr(HttpRequest request)
        {
            return string.Equals(request.Query[HeaderNames.XRequestedWith], "XMLHttpRequest", StringComparison.Ordinal) ||
                string.Equals(request.Headers.XRequestedWith, "XMLHttpRequest", StringComparison.Ordinal);
        }

        options.Events.OnRedirectToLogin = context =>
        {
            if (IsXhr(context.Request))
            {
                context.Response.Headers.Location = context.RedirectUri;
                context.Response.StatusCode = 401;
            }
            else
            {
                context.Response.Redirect(context.RedirectUri);
            }

            return Task.CompletedTask;
        };

        options.Events.OnRedirectToAccessDenied = context =>
        {
            if (IsXhr(context.Request))
            {
                context.Response.Headers.Location = context.RedirectUri;
                context.Response.StatusCode = 403;
            }
            else
            {
                context.Response.Redirect(context.RedirectUri);
            }

            return Task.CompletedTask;
        };
    });

Betroffene APIs

Siehe auch

  • Last updated on