Partager via


IHttpContextAccessor / HttpContextdans les applications ASP.NET Core Blazor

Remarque

Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 10 de cet article.

IHttpContextAccessor généralement doit être évité avec le rendu interactif, car un HttpContext valide n’est pas toujours disponible.

IHttpContextAccessor peut être utilisé lors du rendu côté serveur statique (SSR statique), par exemple dans les composants racines rendus statiquement et lors de l’utilisation d’un gestionnaire de jetons pour les appels d’API web sur le serveur. Nous vous recommandons d’éviter IHttpContextAccessor lorsque le SSR statique ou le code s’exécutant sur le serveur ne peut pas être garanti.

HttpContext peut être utilisé comme paramètre en cascade uniquement dans les composants racines rendus statiquement ou pendant la SSR statique pour les tâches générales, telles que l’inspection et la modification d’en-têtes ou d’autres propriétés dans le App composant (App.razor). La valeur est null pendant le rendu interactif.

[CascadingParameter]
private HttpContext? HttpContext { get; set; }

Pour obtenir des informations supplémentaires sur les cas limites avancés†, consultez la discussion dans les articles suivants :

† Les développeurs les plus avancés qui créent et gèrent Blazor des applications n’ont pas besoin d’examiner les concepts avancés lorsque les conseils généraux de cet article sont suivis. Le concept le plus important à garder à l’esprit est qu’il HttpContext s’agit essentiellement d’une fonctionnalité de réponse aux requêtes basée sur un serveur qui n’est généralement disponible que sur le serveur pendant la SSR statique et créée uniquement lorsque le circuit d’un utilisateur est établi.

Ne définissez pas ou ne modifiez pas d’en-têtes après le démarrage de la réponse

Une tentative de définition ou de modification d’un en-tête après le premier rendu (après le démarrage de la réponse) entraîne une erreur :

System.InvalidOperationException: 'Headers are read-only, response has already started.'

Voici quelques exemples de situations qui entraînent cette erreur :

  • Appeler SignInManager<TUser>.PasswordSignInAsync, qui doit définir des en-têtes pour que Identity fonctionne correctement, tout en adoptant une approche de rendu en streaming.
  • Tentative de définition ou de modification d’un en-tête après le démarrage de la réponse pendant le rendu interactif.

Pour obtenir des conseils sur la définition d'en-têtes avant le début de la réponse, consultez ASP.NET Core Blazor démarrage.

N’utilisez pas IHttpContextAccessor/HttpContext directement ou indirectement dans les composants Razor des applications Blazor côté serveur. Les applications Blazor fonctionnent en dehors du contexte de pipeline d'ASP.NET Core. Le HttpContext n’est pas garanti d’être disponible dans le IHttpContextAccessor, et HttpContext n’est pas garanti de conserver le contexte qui a démarré l’application Blazor.

L’approche recommandée pour passer l’état de la requête à l’application Blazor consiste à utiliser des paramètres de composant racine pendant le rendu initial de l’application. L’application peut également copier les données dans un service délimité dans l’événement de cycle de vie d’initialisation du composant racine pour une utilisation dans l’application. Pour obtenir des informations, consultez ASP.NET Core côté serveur et scénarios supplémentaires de sécurité Blazor Web App.

Un aspect essentiel de la sécurité Blazor côté serveur est que l’utilisateur attaché à un circuit donné peut être mis à jour à un moment donné après l’établissement du circuit Blazor, mais que le IHttpContextAccessorn’est pas mis à jour. Pour plus d’informations sur la résolution de cette situation avec des services personnalisés, consultez ASP.NET Core server-side et Blazor Web App scénarios de sécurité supplémentaires.

Pour obtenir des conseils sur IHttpContextAccessor et HttpContext dans ASP.NET Core SignalR, consultez IHttpContextAccessor/HttpContext dans ASP.NET Core SignalR.