Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Lorsque vous utilisez cookie l’authentification, les points de terminaison d’API retournent les codes d’état HTTP appropriés (tels que 401 ou 403) pour les échecs d’authentification au lieu de rediriger les demandes non authentifiées vers les pages de connexion. Ce comportement, plus adapté à l’accès par programmation aux API, a été introduit dans ASP.NET Core dans .NET 10.
Comment ASP.NET Core identifie les points de terminaison d’API
ASP.NET Core applique automatiquement ce comportement aux points de terminaison qu’il reconnaît comme liés à l’API, notamment :
- Contrôleurs décorés avec l’attribut
[ApiController] - Points de terminaison d’API minimaux inscrits avec
MapGet,MapPost,MapPut,MapDeleteetc. - Points de terminaison qui demandent explicitement des réponses JSON
- SignalR hubs et points de terminaison
Comportement et personnalisation par défaut
Par défaut, ASP.NET Core applique cookie la logique d’authentification en fonction du type de point de terminaison :
- Pages web : rediriger vers les pages de connexion
- Points de terminaison d’API : retourner les codes d’état 401 ou 403 sans redirection
Configuration du comportement
Bien que le comportement par défaut fonctionne pour la plupart des scénarios, il peut être personnalisé si nécessaire :
builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie(options =>
{
options.LoginPath = "/Account/Login";
// The framework automatically handles API endpoints
// No additional configuration needed
});
Si vous devez remplacer la détection automatique pour des points de terminaison spécifiques, utilisez l’attribut [Authorize] avec des schémas d’authentification spécifiques ou implémentez des gestionnaires d’authentification personnalisés.
Considérations relatives à la migration
Ce changement de comportement introduit dans .NET 10 est conçu pour être non cassant pour les applications existantes :
- Applications web : continuer à fonctionner comme avant avec les redirections de page de connexion
- Applications mixtes : les points de terminaison d’API obtiennent des codes d’état appropriés pendant que les pages web reçoivent des redirections
- Applications API uniquement : tirer parti des codes d’état HTTP appropriés sans configuration supplémentaire
Test de vos points de terminaison d’API
Après la mise à niveau vers ASP.NET Core 10, vérifiez que vos points de terminaison d’API retournent les codes d’état appropriés :
[Test]
public async Task UnauthorizedApiRequest_Returns401()
{
var response = await client.GetAsync("/api/secure-data");
Assert.Equal(HttpStatusCode.Unauthorized, response.StatusCode);
Assert.False(response.Headers.Location != null); // No redirect
}