IHttpContextAccessor / HttpContext nelle app ASP.NET Core Blazor

È generalmente meglio evitare IHttpContextAccessor con il rendering interattivo perché un HttpContext valido non è sempre disponibile.

IHttpContextAccessor può essere usato durante il rendering statico lato server (SSR statico), ad esempio nei componenti radice sottoposti a rendering statico e quando si usa un gestore di token per le chiamate API Web nel server. È consigliabile evitare IHttpContextAccessor quando non è possibile garantire l'esecuzione di codice o SSR statico nel server.

HttpContext può essere usato come parametro a catena solo nei componenti radice sottoposti a rendering statico o durante SSR statici per compiti generali, come l'ispezione e la modifica di intestazioni o altre proprietà nel componente App (App.razor). Il valore è null durante il rendering interattivo.

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

Per un contesto aggiuntivo nei casi limite avanzati e†, vedere la discussione negli articoli seguenti:

• HttpContext è valido nella pagina Blazor rendering di Interactive Server (dotnet/AspNetCore.Docs #34301)
• Implicazioni per la sicurezza dell'uso di IHttpContextAccessor in Blazor Server (dotnet/aspnetcore #45699)

† Gli sviluppatori che creano e mantengono Blazor le app non devono approfondire i concetti avanzati quando viene seguita la guida generale in questo articolo. Il concetto più importante da tenere presente è che HttpContext è fondamentalmente una funzionalità basata su server, request-response, disponibile solo a livello generale nel server durante il ssr statico e creata solo quando viene stabilito il circuito di un utente.

Non impostare o modificare le intestazioni dopo l'avvio della risposta

Il tentativo di impostare o modificare un'intestazione dopo il primo rendering (dopo l'avvio della risposta) genera un errore:

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

Esempi di situazioni che generano questo errore includono:

• Chiamando SignInManager<TUser>.PasswordSignInAsync, che deve impostare le intestazioni affinché Identity funzioni correttamente, adottando il rendering in streaming.
• Tentativo di impostare o modificare un'intestazione dopo l'avvio della risposta durante il rendering interattivo.

Per indicazioni sull'impostazione delle intestazioni prima che inizi la risposta, vedere avvio di ASP.NET CoreBlazor.

Non usare IHttpContextAccessor/HttpContext direttamente o indirettamente nei componenti Razor delle app Blazor lato server. Blazor le app vengono eseguite all'esterno del contesto della pipeline ASP.NET Core. Non è garantito che il HttpContext sia disponibile all'interno del IHttpContextAccessor, e non è garantito che il HttpContext contenga il contesto che ha avviato l'app Blazor.

L'approccio consigliato per passare lo stato della richiesta all'app Blazor consiste nell'usare i parametri del componente radice durante il rendering iniziale dell'app. In alternativa, l'app può copiare i dati in un servizio con ambito definito nell'evento del ciclo di vita di inizializzazione del componente radice per un uso più ampio nell'app. Per altre informazioni, vedere ASP.NET Core Blazor altri scenari di sicurezza lato server.

Un aspetto critico della sicurezza Blazor lato server è che l'utente collegato a un determinato circuito potrebbe essere aggiornato in un determinato momento dopo la creazione del circuito Blazor, ma il IHttpContextAccessornon viene aggiornato. Per altre informazioni sulla gestione di questa situazione con servizi personalizzati, vedere ASP.NET Core Blazor altri scenari di sicurezza lato server.