Aspnetcore: Blazor WebAssembly HttpContext is always null

Created on 11 Jun 2020  路  22Comments  路  Source: dotnet/aspnetcore

Describe the bug

Create new Blazor WebAssembly app. Try to access HttpContext from HttpContextAccessor and HttpContext is always null.

To Reproduce

1) Create new Blazor WebAssembly app
2) In Main method of Program.cs of Client project, add:
builder.Services.AddHttpContextAccessor();
builder.Services.AddScoped();
3) Inject HttpContextAccessor into any page
@inject Microsoft.AspNetCore.Http.HttpContextAccessor HttpContextAccessor
4) Try to access HttpContextAccessor.HttpContext and HttpContext is always null

Is there another way to get to TraceIdentifier, Session.Id, etc.?

Exceptions (if any)

None

Further technical details

  • ASP.NET Core version 3.1
  • Include the output of dotnet --info
    PS C:Users\Roy> dotnet --info
    .NET Core SDK (reflecting any global.json):
    Version: 3.1.400-preview-015151
    Commit: 0755a9e324

Runtime Environment:
OS Name: Windows
OS Version: 10.0.18363
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.1.400-preview-015151\

Host (useful for support):
Version: 3.1.5
Commit: 65cd789777

.NET Core SDKs installed:
1.0.0-preview2-003131 [C:\Program Files\dotnet\sdk]
1.0.4 [C:\Program Files\dotnet\sdk]
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.101 [C:\Program Files\dotnet\sdk]
2.1.102 [C:\Program Files\dotnet\sdk]
2.1.201 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.401 [C:\Program Files\dotnet\sdk]
2.1.504 [C:\Program Files\dotnet\sdk]
2.1.505 [C:\Program Files\dotnet\sdk]
2.1.507 [C:\Program Files\dotnet\sdk]
2.1.509 [C:\Program Files\dotnet\sdk]
2.1.512 [C:\Program Files\dotnet\sdk]
2.1.602 [C:\Program Files\dotnet\sdk]
2.1.700 [C:\Program Files\dotnet\sdk]
2.2.203 [C:\Program Files\dotnet\sdk]
3.1.300 [C:\Program Files\dotnet\sdk]
3.1.301 [C:\Program Files\dotnet\sdk]
3.1.400-preview-015151 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.19 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.19 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 1.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.3-servicing-26724-03 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.19 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
PS C:Users\Roy>

  • The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version
    VS2019 16.6.2 on Windows 10
Answered Resolved area-blazor question

All 22 comments

ammending #2:
In Main method of Program.cs of Client project, add:

builder.Services.AddHttpContextAccessor();
builder.Services.AddScoped<HttpContextAccessor>();

A Blazor WebAssembly application runs inside the user's browser sandbox, not in an ASP.NET Core server process. This would explain why it's unavailable. What is it that you're trying to do with the HttpContext?

I would like to get the SessionId or TraceIdentifier to trace a complete transaction from UI thru WebApi.

Our recommendation would be to set up an API on the server that exposes the trace-identifier.

@pranavkm isn't the trace identifier different per request? If the goal is to trace something from the UI through to the web API on the server (and even beyond) I think the trace identifier has to originate from the UI itself, be passed into the API call (a header would be good) and then have the server side code use that as the seed for the trace identifier from there on.

@shirhatti @davidfowl can this be achieved with standard header names and value formats and our support for W3C Trace Context and Open Telemetry?

The way I understood it was that they needed an identifier to uniquely track a session, not necessarily ASP.NET Core's request identifier which is why we recommended having an API to do this. WASM currently does not have a way to send down additional parameters as part of the initial rendering. However, you could get an equivalent behavior by fetching it during the first render.

I guess it all depends on the desired scope of the transaction tracking. In reality one might want both, e.g. a session identifier that correlates to the user session, a transaction identifier that correlates to the logical transaction from the user's point of view.

Feels very related to the activity and w3c trace context.

Thank you for helping. In a "micro-services" environment or and an environment where there are multiple WebApi calls for a single action invoked by the user, it would be very helpful to have a consistent TraceIdentifier thru-out the transaction for debugging and/or performance, etc.

@roysurles that happens today by default in ASP.NET Core. But nothing is created from the webassembly client today AFAIK.

@davidfowl so just setting the outgoing header from the WASM client would make this light-up yeah? Can you point to some pseudo-code as an example?

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.

Parking this in discussion in case @davidfowl wants to respond.

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.

We should provide a sample on how to do this today.

@DamianEdwards where do I find the example?

@DamianEdwards I have the same problem with server sided Blazor on NET5. Our own implementation of an identity provider for mongodb needs to have access to the HttpContext via the injected IHttpContextAccessor. This way we can access HttpContext.User.Claims to retrieve the user id.

The same is needed for external identity providers like Auth0. How can anyone think that the access to the HttpContext is not needed anymore?

This issue should be renamed, accessing the HttpContext in Blazor WASM doesn't make any sense, it's like trying to access the HttpContext in the react or angular. It runs on the client without access to this information.

It sounds like the original ask was about correlation, as for the auth information @javiercn do we have anything for this on the client?

You don't access HttpContext directly on Blazor, you pass the data you need from the context as parameters to the root component on the initial render. I wrote a sample for this here and there are docs available.

As for accessing the user, the right way to do this is through either AuthenticationStateProvider or if you are using CascadingAuthenticationState, then a Task<AuthenticationState> cascading parameter.

@javiercn Is your remark true for server sided Blazor as well?

Yes. See the guidance here

I'm closing this issue since we've answered the question, there are docs available and the current behavior is by design.

Was this page helpful?
0 / 5 - 0 ratings