SignalR gives 404 when using WebSockets or ServerSentEvents for some users but not for others

[Kp0c]

Hi All,

SignalR gives me 404 when trying to connect for some users. URLs are the same except for access_token.

It is stable reproducible per user (I mean that some users are stable OK, some users are stable 404).
Negotiation is fine for all users, and returns next:

access_token parsed jwt diff (left is OK user, right gets 404):

---

I did a trace level of logs and have next:
For the OK user:

For the user that gets 404:

Note: URLs under black squares are the same.

---

Front End is Angular 9 with package "@microsoft/signalr": "^3.1.8", and here's the code that builds the connection:

  private buildHub(): HubConnection {
    console.log(this.authService.accessToken);
    let builder = new HubConnectionBuilder()
                      .withAutomaticReconnect()
                      .configureLogging(LogLevel.Information)
                      .withUrl('ws/notificationHub', {
                          accessTokenFactory: () => this.authService.accessToken
                        });

    if (this.debugMode) {
      builder = builder.configureLogging(LogLevel.Trace);
    }

    return builder.build();
  }

---

Backend is using next code in Startup for configuring signalR hub:

In public void ConfigureServices(IServiceCollection services):

services.AddSignalR()
            .AddJsonProtocol(options =>
            {
                options.PayloadSerializerSettings.ContractResolver = new DefaultContractResolver();
            });

In public void Configure(IApplicationBuilder app, IHostingEnvironment env):

app.UseSignalR(route =>
            {
                route.MapHub<NotificationHub>("/ws/notificationHub");
            });

Also we use custom authentication, so we have Authorize attribute for the Hub class:

    [Authorize]
    public class NotificationHub: Hub<INotificationHubClient>

and this code in public void ConfigureServices(IServiceCollection services):

services.AddAuthentication(IdentityServerAuthenticationDefaults.AuthenticationScheme)
                .AddJwtBearer(options =>
                {
                    options.Authority = identityServerSettings.Url;
                    options.Audience = identityServerSettings.ApiScopeName;
                    options.RequireHttpsMetadata = identityServerSettings.RequireHttpsMetadata;

                    options.Events = new Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerEvents
                    {
                        OnMessageReceived = context =>
                        {
                            var accessToken = context.Request.Query["access_token"];
                            var path = context.HttpContext.Request.Path;
                            if (!string.IsNullOrEmpty(accessToken) && path.StartsWithSegments("/ws"))
                            {
                                context.Token = accessToken;
                            }
                            return Task.CompletedTask;
                        }
                    };
                });

Unfortunately, I don't have the full access to the environment where it is reproducible, but I can request to see any settings or try to make some changes.

What else can I try to troubleshoot my issue?

[BrennanConroy]

For the users that consistently get 404's, do they always succeed with LongPolling?

Can you remove auth from the server to verify that it isn't causing any issues?

Is there anything unique about the users who 404 compared to the users who are successfully using WebSockets? Like are they on a corporate network, or going through a reverse proxy?

Ideally we would like to see server logs and a network trace from the client to diagnose further. https://docs.microsoft.com/aspnet/core/signalr/diagnostics?view=aspnetcore-3.1

[Kp0c]

Thank you very much for your response.

Yes, these users are always succeeding with LongPolling.

Also, I want to note what I mean when saying "user". I mean auth user, as everything that I described on the topic was reproduced on one browser on the same machine with the same application.

Unfortunately, I cannot remove the auth as this app is exposed to the web, but I starting to blame auth the most because it is reproducible only for different auth users (by the way, I'm not sure if it is matters, but it is based on IdentityServer4).

I'll come back when I'll be able to gather more logs.

Thank you very much again :)

[Kp0c]

Hi,

We were able to find the root cause. for these users, JWT was slightly bigger and exceeded the maximum query string of IIS.
After increasing this limit, everything works fine.

Thank you very much for help :~)