Partager via


Les redirections de connexion par cookies sont désactivées pour les points de terminaison d’API connus

Par défaut, les demandes non authentifiées et non autorisées adressées aux points de terminaison d’API connus protégés par l’authentification par cookie entraînent désormais des réponses 401 et 403 plutôt que de rediriger vers un URI de connexion ou d’accès refusé.

Les points de terminaison d’API connus sont identifiés à l’aide de la nouvelle IApiEndpointMetadata interface et les métadonnées implémentant la nouvelle interface ont été ajoutées automatiquement aux éléments suivants :

  • [ApiController] points de terminaison.
  • Points de terminaison d’API minimaux qui lisent les corps de requêtes JSON ou écrivent des réponses JSON.
  • Points de terminaison utilisant TypedResults types de retour.
  • Points de terminaison SignalR.

Version introduite

.NET 10 Preview 7

Comportement précédent

Auparavant, le gestionnaire d’authentification de cookie a redirigé les demandes non authentifiées et non autorisées vers un URI de connexion ou d’accès refusé par défaut pour toutes les requêtes autres que XMLHttpRequests (XHR).

Nouveau comportement

À compter de .NET 10, les requêtes non authentifiées et non autorisées adressées aux points de terminaison d’API connus entraînent des réponses 401 et 403 plutôt que de rediriger vers un URI de connexion ou d’accès refusé. Les XHR continuent d’entraîner des réponses 401 et 403, quel que soit le point de terminaison cible.

Type de changement cassant

Ce changement est un changement de comportement.

Raison de la modification

Ce changement a été fortement demandé. La redirection de requêtes non authentifiées vers une page de connexion n’est généralement pas logique pour les points de terminaison d’API, qui reposent généralement sur les codes d’état 401 et 403 plutôt que sur les redirections HTML pour communiquer les échecs d’authentification.

Si vous souhaitez toujours rediriger vers les URI de connexion et d’accès refusés pour les demandes non authentifiées ou non autorisées, quel que soit le point de terminaison cible ou si la source de la demande est un XHR, vous pouvez remplacer RedirectToLogin et RedirectToAccessDenied comme suit :

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 vous souhaitez revenir au comportement précédent exact qui évite de rediriger uniquement les XHR, vous pouvez remplacer les événements par cette logique légèrement plus complexe :

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

API affectées