HttpContext is valid in Interactive Server Rendering Blazor page

[huazhb]

Description

On the website, it says "IHttpContextAccessor must be avoided with interactive rendering because there isn't a valid HttpContext available." which seems not true. I use the IHttpContextAccessor on the Blazor page using Interactive Server rendering and I can access the HttpContext from IHttpContextAccessor without any issue. When switch to Interactive Client it will be null. (Of course it is since it is running on client side). So, I don't know where this statement coming from, or it will be invalid under some circumstances? Can anyone double check if this statement is valid for all Interactive rendering mode or it is only valid for the Interactive client mode?

Thank you

Page URL

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-context?view=aspnetcore-8.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/fundamentals/http-context.md

Document ID

79cb05f8-9ac0-26a8-8434-15de071160c3

Article author

@guardrex

Related Issues

[guardrex]

Hello @huazhb ... Yes, this is a point of confusion. This section is placed here via an INCLUDE file that also appears in the SignalR article and in the Threat Mitigation article. The section's guidance is the latest that I received from the product unit on the subject. Let's double-check this now and clear this up.

@MackinnonBuck ... This is one of the questions on my list of items to address, so we may as well tackle it now.

Here's the section (via the INCLUDE) ...

<xref:Microsoft.AspNetCore.Http.IHttpContextAccessor> must be avoided with interactive rendering because there isn't a valid `HttpContext` available.

<xref:Microsoft.AspNetCore.Http.IHttpContextAccessor> can be used for components that are statically rendered on the server. **However, we recommend avoiding it if possible.**

<xref:Microsoft.AspNetCore.Http.HttpContext> can be used as a cascading parameter only in *statically-rendered root components* for general tasks, such as inspecting and modifying headers or other properties in the `App` component (`Components/App.razor`). The value is always `null` for interactive rendering.

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

For scenarios where the <xref:Microsoft.AspNetCore.Http.HttpContext> is required in interactive components, we recommend flowing the data via persistent component state from the server. For more information, see <xref:blazor/security/additional-scenarios#pass-tokens-to-a-server-side-blazor-app>.

Cross-reference (LIVE section example): https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-context?view=aspnetcore-8.0#ihttpcontextaccessorhttpcontext-in-razor-components-blazor

That came about from my chat with either (or both) you and Javier.

There's a related issue on the samples repo about this that boils down to code in the BWA+OIDC sample app ...

https://github.com/dotnet/blazor-samples/blob/main/8.0/BlazorWebAppOidcBff/BlazorWebAppOidc/ServerWeatherForecaster.cs

... where the ServerWeatherForecaster is using IHttpContextAccessor to check for an HttpContext. Can you go through the rendering process step-by-step and explain if that code is running interactively or not ... and if it is running interactively (e.g., after prerendering on the server) then how it isn't in conflict with the general guidance on use of IHttpContextAccessor, both the 'don't do it' part and the 'it's always null for interactive rendering' part?

[guardrex]

From Mackinnon offline ...

The IHttpContextAccessor question is something I'm not sure about either. The app gets rendered using the InteractiveAuto render mode, and it seems like things would break if that resolved to using server interactivity. I think Stephen would be the one to ask about that.

Ping to @halter73 to take a look at this issue and recommend updates for the section on IHttpContextAccessor/HttpContext. It looks like we're missing caveats (or it's just plain wrong) ...

• For IHttpContextAccessor, we state that it's ok to use it "for components that are statically rendered on the server."
• For HttpContext, we state that it "can be used as a cascading parameter only in statically-rendered root components for general tasks, such as inspecting and modifying headers or other properties in the App component."

Should these remarks include a caveat for client request processing by the server project, including server-side services used by that processing, or is the current guidance just plain wrong?

[halter73]

We advise against using IHttpContextAccessor in general mostly because managing the flow of the execution context can be tricky and isn't something you otherwise really have to pay attention to. That's why using something like [CascadingParameter] or Hub.Context.GetHttpContext() is preferrable.

That said, as far as I know, using IHttpContextAccessor in the context of a SignalR hub invocation should mostly work. And this includes Blazor events handled by interactive server rendering. In cases where the server-sent events transport is used you'd probably get the HttpContext from the send POST request rather than the text/event-stream request you'd get from calling GetHttpContext() directly inside the SignalR hub, but for many purposes that's probably fine. For long polling things get a bit weirder, but that's not supported by Blazor.

However, I do recall @javiercn mentioning that using IHttpContextAccessor in a Blazor app is insecure. Javier, do you remember this? I don't think I really understood the issue at the time, but maybe if you could explain exactly what makes it insecure, we could add it to the documentation. Sorry, if I'm misremembering anything.

@BrennanConroy @dotnet/aspnet-blazor-eng In case anyone wants to disagree with or add to my assessment.

[BrennanConroy]

For long polling things get a bit weirder, but that's not supported by Blazor.

I don't think that's true unless things changed recently.

In cases where the server-sent events transport is used you'd probably get the HttpContext from the send POST request

I believe the context is still from the long running initial request. Although, SSE is not supported by Blazor as it uses a binary message protocol which SSE doesn't support.

Blazor has things like pre-rendering and InitalizeAsync being called twice (maybe that's pre-rendering?), I don't know if those work with IHttpContextAccessor.

[guardrex]

Steve remarked offline ...

The truth is you can sometimes use IHttpContextAccessor but there are caveats and risks, which is why we’ve found it safer just to tell people not to use it. If our existing guidance is inadequate that may require more thought. Javier would be a great person to give more detailed guidance.

@javiercn, if you're still happy with what we're telling devs ...

• LIVE article section
• INCLUDE file source for the section

... then I think we just need to say why we're going against the advice in the article for the BWA+OIDC sample app ...

https://github.com/dotnet/blazor-samples/blob/main/8.0/BlazorWebAppOidcBff/BlazorWebAppOidc/ServerWeatherForecaster.cs

If people send a few doc issues after that, then I'll point them to this issue discussion. If I see devs regularly opening doc issues on this, then I propose to add a link to the section (and in the BWA+OIDC article with the new content that I'll add there) along the lines of ...

For more information, see [HttpContext is valid in Interactive Server Rendering Blazor page 
(`dotnet/AspNetCore.Docs` #34301)](https://github.com/dotnet/AspNetCore.Docs/issues/34301).