HubFilter should act the same way as an API middleware

[sebastienlabine]

I have an IUserResolver service and an IUserAccessor service inside my API.

When using normal API request, I have a middleware that has the job of resolving the current user and setting it in the IUserAccessor service. This middleware works well and is scoped for the current request.

However, when trying the same thing with IHubFilter, I get very different results. Here's my filter.

    public class UserResolverFilter : IHubFilter
    {
        private IUserResolverService _userResolverService;
        private IUserAccessorService _userAccessorService;
        private readonly ILogger<UserResolverFilter> _logger;
        public UserResolverFilter(IUserResolverService userResolverService, IUserAccessorService userAccessorService, ILogger<UserResolverFilter> logger)
        {
            _userResolverService = userResolverService;
            _userAccessorService = userAccessorService;
            _logger = logger;

        }

        public async ValueTask<object> InvokeMethodAsync(
            HubInvocationContext invocationContext,
            Func<HubInvocationContext, ValueTask<object>> next
            )
        {

            return await next(invocationContext);
        }

        public async Task OnConnectedAsync(HubLifetimeContext context, Func<HubLifetimeContext, Task> next)
        {
            var accessToken = await _userResolverService.ResolveAccessTokenAsync();
            var user = await _userResolverService.ResolveAsync();
            _userAccessorService.AccessToken = accessToken;
            _userAccessorService.User = user;
            if (user == null)
            {
                _logger.LogDebug($"Unauthenticated user with connectionId {context.Context.ConnectionId} connected");
            }
            else
            {
                _logger.LogDebug($"Authenticated User {_userAccessorService.User.UserName} with connectionId {context.Context.ConnectionId} connected");
            }
            await next(context);
        }

        public async Task OnDisconnectedAsync(
            HubLifetimeContext context, Exception exception, Func<HubLifetimeContext, Exception, Task> next)
        {

            if (_userAccessorService.User == null)
            {
                _logger.LogDebug($"Unauthenticated user with connectionId {context.Context.ConnectionId} disconnected");
            }
            else
            {
                _logger.LogDebug($"Authenticated User {_userAccessorService.User.UserName} with connectionId {context.Context.ConnectionId} disconnected");
            }
            await next(context, exception);
        }

And my hub

   public class SessionHub : Hub<ISessionHub>
    {
        private readonly ISessionService _sessionService;

        public classSessionHub (
            ISessionService sessionService
            )
        {
            _sessionService= sessionService;

        }


        public override async Task OnConnectedAsync()
        {
            await base.OnConnectedAsync();
            await _sessionService.CreateAsync(Context.ConnectionId);
        }

        public override async Task OnDisconnectedAsync(Exception exception)
        {
            await _sessionService.DeleteAsync(Context.ConnectionId);
            await base.OnDisconnectedAsync(exception);
        }

Now my ISessionService calls injects my IUserAccessor service and when is constructed, assings the user to a public variable. The problem is that when the constructor is called, the filter has not been executed yet, which is really different of the middleware logic, making assigning null to my user variable.

Is there a way to unify this behaviour so that we can have the same exact "middleware" DI logic for hub filters^

[davidfowl]

I have a middleware that has the job of resolving the current user and setting it in the IUserAccessor service. This middleware works well and is scoped for the current request.

var accessToken = await _userResolverService.ResolveAccessTokenAsync();
var user = await _userResolverService.ResolveAsync();

• What do these calls do?
• What does IUserAccessorService look like?

[sebastienlabine]

@davidfowl

Theses calls to store the user in a scoped service, allowing me to simply inject the userAccessorService in the service instead of always passing the user as a parameter in my service functions. You can think of it like a tenant service. This service is also injected in my DBContext for global query filters.

    public class UserAccessorService : IUserAccessorService
    {
        public SBUser? User { get; set; }
        public string? AccessToken { get; set; }
    }

IUserResolverService

public class UserResolverService : IUserResolverService
    {
        private readonly UserManager<SBUser> _userManager;
        private readonly IHttpContextAccessor _context;


        public UserResolverService(UserManager<SBUser> userManager, IHttpContextAccessor context)
        {
            _userManager = userManager;
            _context = context;
        }
        public async Task<SBUser> ResolveAsync()
        {
            return await _userManager.GetUserAsync(_context.HttpContext.User);
        }
        public async Task<string> ResolveAccessTokenAsync()
        {
            return await _context.HttpContext.GetTokenAsync("access_token");
        }
    }

here's the middleware I was using

 public class UserResolverMiddleware
    {
        private readonly RequestDelegate next;

        public UserResolverMiddleware(RequestDelegate next)
        {
            this.next = next;
        }

        public async Task Invoke(HttpContext context)
        {
            var accessor = context.RequestServices.GetRequiredService<IUserAccessorService>();
            var resolver = context.RequestServices.GetRequiredService<IUserResolverService>();
            var user = await resolver.ResolveAsync();
            var accessToken = await resolver.ResolveAccessTokenAsync();
            accessor.User = user;
            accessor.AccessToken = accessToken;
            await next(context);
        }
    }

[davidfowl]

Right, the problem with this service is that its dependent on the IHttpContextAccessor which doesn't work with SignalR. You should be getting the user from the HubLifetimeContext when using SignalR.

[sebastienlabine]

@davidfowl The thing is my user is actually getting resolved by HTTPContextAccessor. The problem seems to be that my underling services are already constructed before the HubFilter is executed.

Here's my base service that every service inherits from. You can see that I actually associate the _user field to the user found in the accessor service. This value is null because it's contructed before the filter. I can still access _userAccessorService.User directly to have access to my user, but this is where the logic is different than the API middleware

     public ServiceBase(
            IDbContextFactory<SBContext> dbContextFactory,
            IUserAccessorService accessorService,
            IMapper mapper
            )
        {
            _mapper = mapper;
            _dbContextFactory = dbContextFactory;
            _userAccessorService = accessorService;
            _context = CreateDbContext();
            _dbSet = _context.Set<T>();
            _user = _userAccessorService.User;
            _userId = _userAccessorService.UserId;
        }

[davidfowl]

@davidfowl The thing is my user is actually getting resolved by HTTPContextAccessor.

Right but you're getting lucky. You don't want to use the user from the accessor because it might be stale or a disposed reference (in the case of windows auth). You want to use the one that comes from the context SignalR is passing to you.

The problem seems to be that my underling services are already constructed before the HubFilter is executed.

You haven't shown the service registration and their lifetime. Nor have you shown your HubFilter registration.

I wrote something that will go into the docs soon about understanding the hub lifetime.

When using SignalR, there are 2 dependency injection scopes in play, and they are unrelated:

• Request scope
• The hub invocation scope

If you have a scoped service, you will NOT get the same instance of services. I'd need to see more of your project to understand the lifetime issues, but hopefully that provides enough of a hint to get you further in your understanding of the issue.

[sebastienlabine]

Thanks for the clarification about the HTTPContext!

Yes, I feel like it might be a little bit confusing coming for the Rest API where the dependency injection / lifetime of a request is fairly straightfoward.

Thanks for adding the documentation and your help. I'll take a look and try with theses concepts in mind.

[davidfowl]

Yes, I feel like it might be a little bit confusing coming for the Rest API where the dependency injection / lifetime of a request is fairly straightfoward.

You can think of it very similarly but there are 2 separate worlds.

Http request -> new scope -> invoke middleware -> invoke endpoint (new controller e.g.) -> dispose scope
Hub invocation -> new scope -> new hub -> invoke hub method -> dispose hub -> dispose scope

[ricardomomm]

@davidfowl I have a similar case and I think we should have similar feature than a API Middleware for SignalR hubs. Let me explain my scenario:

I have a SignalR application that is multi-tenant, when the request comes in

1. I'm resolving the Tenant from the subdomain in the Request, which works fine in API and SignalR middleware
2. After retrieving the the Tenant it validates the user token using the tenant authentication options, basically custom JwtBearer options with a custom scheme per tenant
3. The authentication goes well and then it leaves the Request and enters the Hub Invocation
4. In the Hub I have a few services that depend on Tenant information to be created (some tenant may have different implementations of a service)
5. That is where it breaks, I cannot access this scope from Hub invocation before the hub is created, or before the service arguments of a method are resolved. I need that to resolve the Tenant again inside the Hub invocation scope, there are no extension points.

In summary, I have all the information to resolve the Tenant, but I cannot resolve before instantiating the dependencies because there are no extension points.

I added a HubFilter, but at the time the HubFilter executes all the Hub dependencies were resolved.

[PatriQ94]

Is there any updates on these issues? I'm facing the same issues and cannot find any solutions.

I have a HubFilter which is supposted to execute before the Hubs, read tenant/user data and store them into a Scoped service like this:

public class TenantFilter : IHubFilter
{
    private readonly IUserInfo _userInfo;
    public TenantFilter(IUserInfo userInfo)
    {
        _userInfo = userInfo;
    }
    public async ValueTask<object> InvokeMethodAsync(HubInvocationContext invocationContext, 
    Func<HubInvocationContext, ValueTask<object>> next)
    {
        HttpContext httpContext = invocationContext.Hub.Context.GetHttpContext();
        //Fills the tenant data into _userInfo
        AuthorizationHelper.ProcessAuthorizationHeaders(_userInfo, httpContext.Request.Headers);

        return await next(invocationContext);
    }
}

I have a Hub which accepts requests like this:

[SignalRHub]
public class ScreeningHub : Hub
{
    public async Task TriggerScreening([FromServices] IScreeningService _screeningService)
    {
        _screeningService.TriggerScreening();
    }
}

Which calls a Scoped service which looks like this:

public class ScreeningService : IScreeningService
{
    private readonly IScreeningRepository _screeningRepository;
    public ScreeningService(IScreeningRepository screeningRepository)
    {
        _screeningRepository = screeningRepository;
    }
	
    public async Task<bool> TriggerScreening()
    {
        return await _screeningRepository.DoSomething();
    }
}

Which calls a Scoped repository which looks like this:

public class ScreeningRepository : IScreeningRepository
{
    private readonly string tenantId;
    public ScreeningRepository(IUserInfo userInfo)
    {
        //UserInfo here is empty
        tenantId = userInfo.GetTenant();
    }
	
    public async Task<bool> DoSomething()
    {
	//Can't do anything because tenantId here is empty
        return false;
    }
}

And here the UserInfo is empty. Because the ScreeningRepository was instantiated before the HubFilter was executed, leaving the dependency injection broken.

[ricardomomm]

Bump! This is very needed!

[davidfowl]

For now you have to resolve dependencies from the invoke method using the service provider instead of the constructor.