Enable WebSocketFactory Configuration for Browser Platforms in SignalR

[a-scollin]

Summary

Allow configuration of WebSocketFactory on browser platforms in SignalR to enable advanced customization and reduce boilerplate for scenarios where query string-based authentication is required.

Unsure why this OS specific check is required:

aspnetcore/src/SignalR/clients/csharp/Http.Connections.Client/src/HttpConnectionFactory.cs

Line 95 in 62c4728

if (!OperatingSystem.IsBrowser())

Motivation and goals

When using SignalR in browser environments, the WebSocketFactory property from HttpConnectionOptions is silently ignored during HubConnection setup in HubConnectionFactory. Currently this configuration object is shallow copied and some properties are dropped depending on OS, this means the default WebSocketFactory method in (

aspnetcore/src/SignalR/clients/csharp/Http.Connections.Client/src/Internal/WebSocketsTransport.cs

Line 305 in 62c4728

var factory = _httpConnectionOptions.WebSocketFactory ?? DefaultWebSocketFactory;

) is always used when on browser.

This behavior is not clearly documented and prevents developers from customizing WebSocket behavior--such as injecting query string parameters for authentication (not just "access_token") --without resorting to verbose boilerplate code. The lack of configurability limits flexibility for advanced scenarios, even when the desired customization is compatible with browser WebSocket APIs.

In scope

• Flexible Authentication via Query String not restricted to providing access_token

• Advanced WebSocket Customization in Browser using SignalR

• Reducing Boilerplate -- currently need to adjust the Hub Url manually

• Improved Developer Experience and Transparency using SignalR

Out of scope

Cross-platform WebSocket Compatibility Guarantees - We are not requesting SignalR to guarantee consistent behavior across all platforms—only that developers be allowed to opt into customization where feasible.

Risks / unknowns

Security Misuse
Exposing low-level configuration could lead to misuse (e.g., passing sensitive data via query strings) if not clearly guided

Browser API Limitations

Native browser WebSocket APIs may restrict certain customizations, which could limit the effectiveness of exposing WebSocketFactory in some environments.

Examples

• Use service provider to customize the default ClientWebSocket behaviour
• Use an extended version of the ClientWebSocket class

[BrennanConroy]

Seems fine, looks like it might have been an oversight when I reviewed the original change that added this.

Marking as help-wanted in case anyone would like to move the shallow copied property.

[dotnet-policy-service]

Looks like this issue has been identified as a candidate for community contribution. If you're considering sending a PR for this issue, look for the Summary Comment link in the issue description. That comment has been left by an engineer on our team to help you get started with handling this issue. You can learn more about our Help Wanted process here