From 4393b8283d3293b33b323c475f788d50cbf6cbf3 Mon Sep 17 00:00:00 2001 From: guardrex <1622880+guardrex@users.noreply.github.com> Date: Mon, 16 Aug 2021 07:22:45 -0500 Subject: [PATCH 1/3] Long Polling disabled update --- aspnetcore/blazor/fundamentals/signalr.md | 34 +++++++++++++++++++ aspnetcore/blazor/host-and-deploy/server.md | 9 ++++- .../security/server/threat-mitigation.md | 11 ++++-- 3 files changed, 51 insertions(+), 3 deletions(-) diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md index 8b8fdb2a53c0..509372725a8b 100644 --- a/aspnetcore/blazor/fundamentals/signalr.md +++ b/aspnetcore/blazor/fundamentals/signalr.md @@ -350,6 +350,40 @@ When a circuit ends because a user has disconnected and the framework is cleanin We recommend using the [Azure SignalR Service](xref:signalr/scale#azure-signalr-service) for Blazor Server apps hosted in Microsoft Azure. The service works in conjunction with the app's Blazor Hub for scaling up a Blazor Server app to a large number of concurrent SignalR connections. In addition, the SignalR Service's global reach and high-performance data centers significantly aid in reducing latency due to geography. For prerendering support with the Azure SignalR Service, configure the app to use *sticky sessions*. For more information, see . +## Enable Long Polling + +Long Polling was enabled in releases prior to ASP.NET Core 6.0 as a fallback transport for situations in which WebSockets weren't available. If an app targeting ASP.NET Core 6.0 or later must use Long Polling, make the following server-side and client-side changes: + +Server-side update: + +In `Startup.cs`, replace `endpoints.MapBlazorHub()` with: + +```csharp +endpoints.MapBlazorHub(configureOptions: options => +{ + options.Transports = HttpTransportType.WebSockets | HttpTransportType.LongPolling; +}); +``` + +Client-side update: + +Add the following script to the `Shared/_Layout.cshtml` file immediately inside the closing `` tag. WebSockets (`1`) and Long Polling (`4`) are supported `HTTPTransportTypes`. The following example: + +* Specifies support for both WebSockets and Long Polling transports (`1 | 4`). +* Defaults to WebSockets when a WebSockets connection can be established. + +```html + +``` + +For more information, see [Disable Long Polling Fallback Transport for Blazor Server (ASP.NET Announcements)](https://github.com/aspnet/Announcements/issues/470). + ## Additional resources * diff --git a/aspnetcore/blazor/host-and-deploy/server.md b/aspnetcore/blazor/host-and-deploy/server.md index e90219a46b0a..91987e873f18 100644 --- a/aspnetcore/blazor/host-and-deploy/server.md +++ b/aspnetcore/blazor/host-and-deploy/server.md @@ -45,7 +45,12 @@ Each circuit uses approximately 250 KB of memory for a minimal *Hello World*-sty Blazor Server apps use ASP.NET Core SignalR to communicate with the browser. [SignalR's hosting and scaling conditions](xref:signalr/publish-to-azure-web-app) apply to Blazor Server apps. -Blazor works best when using WebSockets as the SignalR transport due to lower latency, reliability, and [security](xref:signalr/security). Long Polling is used by SignalR when WebSockets isn't available or when the app is explicitly configured to use Long Polling. When deploying to Azure App Service, configure the app to use WebSockets in the Azure portal settings for the service. For details on configuring the app for Azure App Service, see the [SignalR publishing guidelines](xref:signalr/publish-to-azure-web-app). +Blazor works best when using WebSockets as the SignalR transport due to lower latency, reliability, and [security](xref:signalr/security). When deploying to Azure App Service, configure the app to use WebSockets in the Azure portal settings for the service. For details on configuring the app for Azure App Service, see the [SignalR publishing guidelines](xref:signalr/publish-to-azure-web-app). + +> [!NOTE] +> In releases prior to ASP.NET Core 6.0, Long Polling was enabled as a fallback transport for situations in which WebSockets weren't available. If an app targeting ASP.NET Core 6.0 or later must use Long Polling, see . +> +> For more information, see [Disable Long Polling Fallback Transport for Blazor Server (ASP.NET Announcements)](https://github.com/aspnet/Announcements/issues/470). #### Azure SignalR Service @@ -56,6 +61,8 @@ We recommend using the [Azure SignalR Service](xref:signalr/scale#azure-signalr- > > We recommend using WebSockets for Blazor Server apps deployed to Azure App Service. The [Azure SignalR Service](xref:signalr/scale#azure-signalr-service) uses WebSockets by default. If the app doesn't use the Azure SignalR Service, see . > +> As of the release of ASP.NET Core 6.0, Long Polling isn't enabled by default. For more information, see the [SignalR configuration](#signalr-configuration) section. +> > For more information, see: > > * [What is Azure SignalR Service?](/azure/azure-signalr/signalr-overview) diff --git a/aspnetcore/blazor/security/server/threat-mitigation.md b/aspnetcore/blazor/security/server/threat-mitigation.md index 9a0e856203ad..e7c4cba288f5 100644 --- a/aspnetcore/blazor/security/server/threat-mitigation.md +++ b/aspnetcore/blazor/security/server/threat-mitigation.md @@ -84,10 +84,17 @@ By default, there's no limit on the number of connections per user for a Blazor * Require authentication to connect to the app and keep track of the active sessions per user. * Reject new sessions upon reaching a limit. * Proxy WebSocket connections to an app through the use of a proxy, such as the [Azure SignalR Service](/azure/azure-signalr/signalr-overview) that multiplexes connections from clients to an app. This provides an app with greater connection capacity than a single client can establish, preventing a client from exhausting the connections to the server. - * At the server level: Use a proxy/gateway in front of the app. For example, [Azure Front Door](/azure/frontdoor/front-door-overview) enables you to define, manage, and monitor the global routing of web traffic to an app and works when Blazor Server apps are configured to use Long Polling. + * At the server level: Use a proxy/gateway in front of the app. > [!NOTE] - > Although Long Polling is supported for Blazor Server apps, [WebSockets is the recommended transport protocol](xref:blazor/host-and-deploy/server#azure-signalr-service). [Azure Front Door](/azure/frontdoor/front-door-overview) doesn't support WebSockets at this time, but support for WebSockets is under consideration for a future release of the service. + > Long Polling isn't enabled by default for ASP.NET Core 6.0 or later Blazor Server apps. [Azure Front Door](/azure/frontdoor/front-door-overview) doesn't support WebSockets at this time, but support for WebSockets is under consideration for a future release of the service. + > + > For more information, see the following resources: + > + > * + > * + > * [Disable Long Polling Fallback Transport for Blazor Server (ASP.NET Announcements)](https://github.com/aspnet/Announcements/issues/470) + > * [Support WebSocket connections on Azure Front Door](https://feedback.azure.com/forums/217313-networking/suggestions/37346371-support-websocket-connections-on-azure-front-door) ## Denial of service (DoS) attacks From 3dcb4892fef7164af993dcd0ba52ab9602797ced Mon Sep 17 00:00:00 2001 From: Luke Latham <1622880+guardrex@users.noreply.github.com> Date: Tue, 17 Aug 2021 14:20:39 -0500 Subject: [PATCH 2/3] Update aspnetcore/blazor/fundamentals/signalr.md Co-authored-by: Tanay Parikh --- aspnetcore/blazor/fundamentals/signalr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md index 509372725a8b..fe35464d486f 100644 --- a/aspnetcore/blazor/fundamentals/signalr.md +++ b/aspnetcore/blazor/fundamentals/signalr.md @@ -367,7 +367,7 @@ endpoints.MapBlazorHub(configureOptions: options => Client-side update: -Add the following script to the `Shared/_Layout.cshtml` file immediately inside the closing `` tag. WebSockets (`1`) and Long Polling (`4`) are supported `HTTPTransportTypes`. The following example: +Add the following script to the `Shared/_Layout.cshtml` file immediately inside the closing `` tag. WebSockets (`1`) and Long Polling (`4`) are the supported `HTTPTransportTypes`. The following example: * Specifies support for both WebSockets and Long Polling transports (`1 | 4`). * Defaults to WebSockets when a WebSockets connection can be established. From 7c75b1133268b827fdcc5b538a5ac7fc5bca5578 Mon Sep 17 00:00:00 2001 From: guardrex <1622880+guardrex@users.noreply.github.com> Date: Thu, 19 Aug 2021 07:31:57 -0500 Subject: [PATCH 3/3] Updates --- aspnetcore/blazor/fundamentals/signalr.md | 15 ++++++--------- aspnetcore/blazor/host-and-deploy/server.md | 2 +- .../blazor/security/server/threat-mitigation.md | 2 +- 3 files changed, 8 insertions(+), 11 deletions(-) diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md index fe35464d486f..3b30f4604962 100644 --- a/aspnetcore/blazor/fundamentals/signalr.md +++ b/aspnetcore/blazor/fundamentals/signalr.md @@ -350,27 +350,24 @@ When a circuit ends because a user has disconnected and the framework is cleanin We recommend using the [Azure SignalR Service](xref:signalr/scale#azure-signalr-service) for Blazor Server apps hosted in Microsoft Azure. The service works in conjunction with the app's Blazor Hub for scaling up a Blazor Server app to a large number of concurrent SignalR connections. In addition, the SignalR Service's global reach and high-performance data centers significantly aid in reducing latency due to geography. For prerendering support with the Azure SignalR Service, configure the app to use *sticky sessions*. For more information, see . -## Enable Long Polling +## Long Polling -Long Polling was enabled in releases prior to ASP.NET Core 6.0 as a fallback transport for situations in which WebSockets weren't available. If an app targeting ASP.NET Core 6.0 or later must use Long Polling, make the following server-side and client-side changes: +Long Polling was enabled in releases prior to ASP.NET Core 6.0 as a fallback transport for situations in which the WebSockets transport wasn't available. If an app targeting ASP.NET Core 6.0 or later must use Long Polling, make the following changes: -Server-side update: - -In `Startup.cs`, replace `endpoints.MapBlazorHub()` with: +In the app's `Startup.cs` file, replace `endpoints.MapBlazorHub()` with the following code: ```csharp endpoints.MapBlazorHub(configureOptions: options => { - options.Transports = HttpTransportType.WebSockets | HttpTransportType.LongPolling; + options.Transports = + HttpTransportType.WebSockets | HttpTransportType.LongPolling; }); ``` -Client-side update: - Add the following script to the `Shared/_Layout.cshtml` file immediately inside the closing `` tag. WebSockets (`1`) and Long Polling (`4`) are the supported `HTTPTransportTypes`. The following example: * Specifies support for both WebSockets and Long Polling transports (`1 | 4`). -* Defaults to WebSockets when a WebSockets connection can be established. +* Defaults to the WebSockets transport when a WebSockets connection can be established. ```html