Teilen über

IHttpContextAccessor / HttpContextin ASP.NET Core-Apps Blazor

Hinweis

Dies ist nicht die neueste Version dieses Artikels. Die aktuelle Version finden Sie in der .NET 10-Version dieses Artikels.

IHttpContextAccessor sollte im Allgemeinen bei interaktivem Rendering vermieden werden, da ein gültiger HttpContext nicht immer verfügbar ist.

IHttpContextAccessor kann während des statischen serverseitigen Renderings (statischer SSR) verwendet werden, z. B. in statisch gerenderten Stammkomponenten und bei Verwendung eines Tokenhandlers für Web-API-Aufrufe auf dem Server. Wir empfehlen, IHttpContextAccessor zu vermeiden, wenn statische SSR oder der auf dem Server laufende Code nicht garantiert werden kann.

HttpContext kann nur als kaskadierender Parameter in statisch gerenderten Stammkomponenten oder während statischer SSR für allgemeine Aufgaben verwendet werden, z. B. beim Überprüfen und Ändern von Headern oder anderen Eigenschaften in der App Komponente (App.razor). Der Wert ist null während des interaktiven Renderns.

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

Für zusätzlichen Kontext in erweiterten Randfällen† siehe die Diskussion in den folgenden Artikeln:

†Die meisten Entwickler, die Blazor-Apps erstellen und verwalten, müssen sich nicht mit erweiterten Konzepten befassen, wenn die allgemeinen Richtlinien in diesem Artikel befolgt werden. Das wichtigste Konzept, das Sie berücksichtigen sollten, ist, dass HttpContext grundsätzlich ein serverbasiertes Anforderungs-Antwort-Funktion ist, das im Allgemeinen auf dem Server während statischer SSR verfügbar ist und nur erstellt wird, wenn der Benutzercircuit eingerichtet wird.

Legen Sie keine Kopfzeilen fest und ändern Sie diese nicht, nachdem der Antwortvorgang begonnen hat.

Beim Versuch, einen Header nach dem ersten Rendering (nach dem Start der Antwort) festzulegen oder zu ändern, tritt ein Fehler auf:

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

Beispiele für Situationen, die zu diesem Fehler führen, sind:

  • Das Aufrufen von SignInManager<TUser>.PasswordSignInAsync, wobei Header für Identity festgelegt werden müssen, damit es ordnungsgemäß funktioniert, während das Streaming-Rendering angenommen wird.
  • Beim Versuch, einen Header festzulegen oder zu ändern, nachdem die Antwort während des interaktiven Renderings gestartet wurde.

Anleitungen zum Festlegen von Headern vor dem Start der Antwort finden Sie unter ASP.NET Core-StartBlazor.

Verwenden Sie IHttpContextAccessor/HttpContext nicht direkt oder indirekt in den Razor-Komponenten serverseitiger Blazor-Apps. Blazor-Apps werden außerhalb des ASP.NET Core-Pipelinekontexts ausgeführt. Die Verfügbarkeit von HttpContext in IHttpContextAccessor kann nicht sichergestellt, und es ist auch nicht gewährleistet, dass HttpContext den Kontext zum Starten der Blazor-App enthält.

Der empfohlene Ansatz für das Übergeben des Anforderungsstatus an die Blazor-App erfolgt über Stammkomponentenparameter während des anfänglichen Renderings der App. Alternativ kann die App die Daten in einen bereichsbezogenen Dienst im Initialisierungslebenszyklusereignis der Stammkomponente kopieren, um sie in der gesamten App zu verwenden. Weitere Informationen finden Sie unter ASP.NET Core serverseitig und Blazor Web App zusätzliche Sicherheitsszenarien.

Ein wichtiger Aspekt der serverseitigen Blazor-Sicherheit ist, dass der Benutzer, der an eine bestimmte Verbindung angefügt ist, möglicherweise irgendwann aktualisiert wird, nachdem die Blazor-Verbindung hergestellt wurde, der IHttpContextAccessor aber nicht aktualisiert wird. Weitere Informationen zum Beheben dieses Problems mit benutzerdefinierten Diensten finden Sie unter ASP.NET Core serverseitig und Blazor Web App zusätzliche Sicherheitsszenarien.

Anleitungen zu IHttpContextAccessor und HttpContext in ASP.NET Core SignalRfinden Sie unter "IHttpContextAccessor/HttpContext" in ASP.NET Core SignalR.

  • Last updated on