Compartir a través de

Las redirecciones de inicio de sesión de cookies están deshabilitadas para los puntos de conexión de API conocidos

De forma predeterminada, las solicitudes no autenticadas y no autorizadas realizadas a puntos de conexión de API conocidos protegidos por la autenticación de cookies ahora dan lugar a respuestas 401 y 403 en lugar de redirigir a un URI de inicio de sesión o acceso denegado.

Los puntos de conexión de API conocidos se identifican mediante la nueva IApiEndpointMetadata interfaz y los metadatos que implementan la nueva interfaz se han agregado automáticamente a lo siguiente:

  • [ApiController] Puntos de conexión.
  • Puntos de conexión de API mínimos que leen cuerpos de solicitud JSON o escriben respuestas JSON.
  • Puntos de conexión que usan TypedResults tipos de retorno.
  • Puntos de conexión de SignalR.

Versión introducida

.NET 10 Preview 7

Comportamiento anterior

Anteriormente, el controlador de autenticación de cookies redirigió las solicitudes no autenticadas y no autorizadas a un URI de inicio de sesión o denegado de acceso de forma predeterminada para todas las solicitudes que no sean XMLHttpRequests (XHR).

Nuevo comportamiento

A partir de .NET 10, las solicitudes no autenticadas y no autorizadas realizadas a puntos de conexión de API conocidos dan lugar a respuestas 401 y 403 en lugar de redirigir a un URI de inicio de sesión o acceso denegado. Las XHR siguen dando lugar a respuestas 401 y 403 independientemente del punto de conexión de destino.

Tipo de cambio disruptivo

Este es un cambio de comportamiento.

Motivo del cambio

Este cambio fue muy solicitado. La redirección de solicitudes no autenticadas a una página de inicio de sesión no suele tener sentido para los puntos de conexión de API, que normalmente se basan en códigos de estado 401 y 403 en lugar de redireccionamientos HTML para comunicar errores de autenticación.

Si desea redirigir siempre a los URI de inicio de sesión y denegado de acceso para solicitudes no autenticadas o no autorizadas, independientemente del punto de conexión de destino o si el origen de la solicitud es un XHR, puede invalidar RedirectToLogin y RedirectToAccessDenied de la siguiente manera:

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

Si desea revertir al comportamiento anterior exacto que evita el redireccionamiento solo para XHR, puede invalidar los eventos con esta lógica ligeramente más complicada:

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

Las APIs afectadas

  • Last updated on