Freigeben über

Cookie-Login-Umleitungen sind für bekannte API-Endpunkte deaktiviert.

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

Bekannte API-Endpunkte werden mithilfe der neuen IApiEndpointMetadata 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 Rückgabetypen verwenden TypedResults .
  • SignalR-Endpunkte.

Eingeführte 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.

Wenn Sie immer zu den Anmelde- und Zugriffsverweigerungs-URIs für nicht authentifizierte oder nicht autorisierte Anforderungen umleiten möchten, unabhängig davon, ob es sich beim Zielendpunkt um einen bestimmten Endpoint handelt oder die Quelle der Anforderung ein XHR ist, können Sie RedirectToLogin und RedirectToAccessDenied folgendermaßen außer Kraft setzen:

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

  • Last updated on