Udostępnij przez

Przekierowania logowania przy użyciu plików cookie są wyłączone dla znanych punktów końcowych API.

Domyślnie nieuwierzytelnione i nieautoryzowane żądania do znanych punktów końcowych API chronionych przez uwierzytelnianie za pomocą ciasteczek teraz skutkują odpowiedziami 401 i 403, a nie przekierowaniem do adresu URI logowania lub odmowy dostępu.

Znane punkty końcowe interfejsu API są identyfikowane przy użyciu nowego IApiEndpointMetadata interfejsu, a metadane implementowania nowego interfejsu zostały automatycznie dodane do następujących elementów:

  • [ApiController] Interfejsy końcowe.
  • Minimalne punkty końcowe interfejsu API, które odczytują treści żądań JSON lub zapisują odpowiedzi JSON.
  • Punkty końcowe korzystające z TypedResults typów zwracanych.
  • Punkty końcowe usługi SignalR.

Wersja wprowadzona

.NET 10 (wersja zapoznawcza 7)

Poprzednie zachowanie

Wcześniej obsługa uwierzytelniania za pomocą plików cookie przekierowywała nieuwierzytelnione i nieautoryzowane żądania do URI logowania lub odmowy dostępu standardowo dla wszystkich żądań innych niż XMLHttpRequests (XHRs).

Nowe zachowanie

Począwszy od platformy .NET 10, nieuwierzytelnione i nieautoryzowane żądania wysyłane do znanych punktów końcowych interfejsu API skutkują kodami odpowiedzi 401 i 403, a nie przekierowaniem do identyfikatora URI logowania lub odmowy dostępu. Żądania XHRs nadal skutkują odpowiedziami 401 i 403 niezależnie od docelowego punktu końcowego.

Typ zmiany przełamującej

Ta zmiana jest zmianą behawioralną.

Przyczyna zmiany

Ta zmiana została bardzo żądana. Przekierowywanie nieuwierzytelnionych żądań do strony logowania zwykle nie ma sensu w przypadku punktów końcowych interfejsu API, które zwykle korzystają z kodów stanu 401 i 403, a nie przekierowań HTML do przekazywania błędów uwierzytelniania.

Jeśli chcesz zawsze przekierowywać do URI logowania i URI odmowy dostępu dla nieautoryzowanych lub nieuwierzytelnionych żądań niezależnie od punktu końcowego lub tego, czy źródłem żądania jest XHR, możesz nadpisać RedirectToLogin i RedirectToAccessDenied w następujący sposób:

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

Jeśli chcesz powrócić do poprzedniego zachowania, które pozwala uniknąć przekierowania tylko dla XHRs, możesz zastąpić zdarzenia nieco bardziej zaawansowaną logiką:

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

Interfejsy API, których dotyczy problem

  • Last updated on