IHttpContextAccessor is null on some environments in a Blazor project

[royberris]

I know the IHttpContext is only supposed to be set on the initial request to the server. But I am seeing some irregularities.

I am getting the _httpContextAccessor.HttpContext.User.Identity.Name to see which user is logged in. This exists in my business logic and both my API and my CMS use this. This is getting called in a IdentityService class which I made and is added as a scoped service. This class has a property called CurrentUser.

public AppUser CurrentUser
        {
            get
            {
                if (_currentUser == null)
                {
                    var identityNameClaims = _httpContextAccessor.HttpContext.User.Identity.Name;

                     _currentUser = _appUserRepository.Get(identityNameClaims);
                }

                return _currentUser;
            }
        }

Seeing it is added as a scoped service. Shouldn't the CurrentUser keep its value?

When running my project locally with Visual Studio through either IIS Express or Kestrel it simply works. Every request I make in Blazor can access the user claims. I use this to display the user info on certain pages of my application. It is never null. I confirmed this by debugging locally.

When I published it to my VPS running Windows Server 2019 Datacenter and IIS with dotnet 5.0.6 this is not the case. Initial request works and I do see the user info on the page (probably because of the pre-render by Blazor). But after that the connection is closed and I get a error in the javascript console saying that the IHttpContextAccessor is null.

I installed remote debugger on the VPS and published my application as a debug build. I am calling the IHttpContextAccessor directly in my App.razor OnInitialized method. The breakpoint hits twice, first time it is not null. Second time it hits it is null. Btw I did not know the OnInitialized method is called twice.

So my question is, there is a difference in the environment that makes this work locally (and on a Ubuntu server I have running at home) but not on a Windows Server. What could this be, and how do I make sure it is persistent on every environment?

Also other tips on how to implement this properly are welcome.

[javiercn]

@royberris thanks for contacting us.

Use of IHttpContext accessor is discouraged within Blazor. See here for details and guidance.

[royberris]

@javiercn thanks for your answer and I've read the docs you've provided. But still this is not working.

It does work locally using visual studio. But it does not work on IIS on a remote server.

I have a service which is added as a scoped service. In the App.OnInitialized method I am fetching the data I need with the IHttpContextAccessor. Now I save this data in the scoped service. Works all fine, except that the scope seems to reset?

When I debug the first time it hits the OnInitialized method it all works fine. But the second time it does not, now we get an exception that the IHttpContextAccessor is null. I do have a check in place to see if the data is already received, if not then fetch it. Weird thing is, in the local visual studio session both times the IHttpContextAccessor is not null.

The property CurrentUser which is in the scoped service is also null on the second request. That means the scope has reset, or a new scope is created? Anyway the docs provided are not true. This approach does not work on remote server running IIS with the net runtime 5.0.6, but again on a local visual studio debug session it does work.

---

Code below, I took out irrelevant code to make it more readable.

App.razor

@inject AuthStateService _authState;

...

@code {
    protected override void OnInitialized()
    {
        _authState.FetchCurrentUser();
    }
}

AuthStateService.cs

public class AuthStateService
    {
        private readonly IUserService _userService;

        public AuthStateService(IUserService userService)
        {
            _userService = userService;
        }

        public AppUser CurrentUser { get; private set; }

        public void FetchCurrentUser()
        {
            if (CurrentUser != null)
            {
                return;
            }

            CurrentUser = _userService.CurrentUser;
        }
    }

Below is in another project in the solution containing all the business logic for the API and CMS.

IUserService.cs

public interface IUserService
    {
        public bool IsLoggedIn { get; }

        public AppUser CurrentUser { get; }
    }

IdentityService.cs

internal class IdentityService : IUserService
    {
        private readonly SignInManager<AppUserEntity> _signInManager;
        private readonly UserManager<AppUserEntity> _userManager;
        private readonly AppUserRepository _appUserRepository;
        private readonly IHttpContextAccessor _httpContextAccessor;

        private AppUser _currentUser;

        public IdentityService(
            SignInManager<AppUserEntity> signInManager,
            UserManager<AppUserEntity> userManager,
            AppUserRepository appUserRepository,
            IHttpContextAccessor httpContextAccessor)
        {
            _signInManager = signInManager;
            _userManager = userManager;
            _appUserRepository = appUserRepository;
            _httpContextAccessor = httpContextAccessor;
        }

        public AppUser CurrentUser
        {
            get
            {
                if (_currentUser == null)
                {
                    // below is null on second time `OnInitialized` is hit. But should be `_currentUser` be set because it is a scoped service.
                    var identityNameClaims = _httpContextAccessor.HttpContext.User.Identity.Name;

                    if (Guid.TryParse(identityNameClaims, out _))
                    {
                        _currentUser = _appUserRepository.Get(identityNameClaims);
                    }
                }

                return _currentUser;
            }
        }
}

Everything is added as scoped in the startup.

[javiercn]

@royberris I don't think you are following the guidance correctly.

You should not depend on IHttpContextAccessor at all on Blazor applications. It will not work as you expect. Instead you need to capture all values you need within _Host.cshtml and pass those values as parameters to the root component you are rendering. From there you can choose to either set them up on a service or expose them as cascadingparameters to the rest of the app.

Blazor applications don't run in the context of an HTTP request and don't have an associated HttpContext instance with them. Check this sample for details

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.