ASP.NET Core SignalR 中的安全性考慮

作者:Andrew Stanton-Nurse

本文提供保護 SignalR 的相關資訊。

跨原始來源資源共用

跨原始來源資源分享 (CORS) 可用來允許瀏覽器中的跨原始來源 SignalR 連線。 如果 JavaScript 程式碼裝載於與 SignalR 應用程式不同的網域上,則必須啟用 CORS 中介軟體 ,才能讓 JavaScript 連線到 SignalR 應用程式。 只允許來自您信任或控制之網域的跨原始來源要求。 例如:

  • 您的網站裝載於 http://www.example.com
  • 您的 SignalR 應用程式裝載於 http://signalr.example.com

CORS 應該在 SignalR 應用程式中設定為只允許原始 www.example.com

如需設定 CORS 的詳細資訊,請參閱啟用跨原始來源要求 (CORS)。 SignalR需要下列 CORS 原則:

  • 允許特定的預期來源。 允許任何來源是可行的,但不是安全或建議的項目。
  • 必須允許 HTTP 方法 GETPOST
  • 必須允許認證,才能讓 cookie型黏性工作階段正常運作。 即使未使用驗證,也必須啟用它們。

不過,在 5.0 中,我們已在 TypeScript 用戶端中提供選項,以不使用認證。 只有在您知道應用程式中不需要 Cookie等認證的 100% 時,才應該使用不使用認證的選項 (cookie在使用多部伺服器進行黏性工作階段時,Azure App Service 會使用認證)。

例如,下列醒目提示的 CORS 原則可讓SignalR裝載在 上的https://example.com瀏覽器用戶端存取裝載的應用程式SignalRhttps://signalr.example.com

using SignalRChat.Hubs;

var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowSpecificOrigins,
                      policy =>
                      {
                          policy.WithOrigins("http://example.com");
                          policy.WithMethods("GET", "POST");
                          policy.AllowCredentials();
                      });
});

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

app.MapHub<ChatHub>("/chatHub");

在上一個範例中,CORS 原則會自定義為允許特定來源、方法和認證。 如需在 ASP.NET Core 中自定義 CORS 原則和中間件的詳細資訊,請參閱 CORS 中間件:具有具名原則和中間件的 CORS。

WebSocket 來源限制

CORS 所提供的保護不套用至 WebSocket。 如需 WebSocket 的原點限制,請參閱 WebSockets 原始限制

ConnectionId

如果 SignalR 伺服器或用戶端版本 ASP.NET Core 2.2 或更早版本,公開 ConnectionId 可能會導致惡意模擬。 如果 SignalR 伺服器和用戶端版本 ASP.NET Core 3.0 或更新版本,則 ConnectionToken 而非 ConnectionId 必須保密。 ConnectionToken 的目的是不會在任何 API 中公開。 很難確保較舊的 SignalR 用戶端不會連線到伺服器,因此即使您的 SignalR 伺服器版本 ASP.NET Core 3.0 或更新版本,ConnectionId 也不應該公開。

存取權杖記錄

使用 WebSockets 或伺服器傳送事件時,瀏覽器用戶端會在查詢字串中傳送存取權杖。 透過查詢字串接收存取權杖通常和使用標準 Authorization 標頭一樣安全。 一律使用 HTTPS 來確保用戶端與伺服器之間的端對端連線安全。 許多網頁伺服器都會記錄每個要求的 URL,包括查詢字串。 記錄 URL 可能會記錄存取權杖。 ASP.NET Core 預設會記錄每個要求的 URL,其中包含查詢字串。 例如:

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

如果您擔心使用伺服器記錄來記錄此資料,您可以將 Microsoft.AspNetCore.Hosting 記錄器設定為 Warning 層級或更新版本,以完全停用此記錄 (這些訊息是以 Info 層級撰寫)。 如需詳細資訊,請參閱在程式碼中套用記錄篩選規則以取得詳細資訊。 如果您仍想要記錄特定要求資訊,您可以寫入中介軟體來記錄您需要的資料,並篩選出 access_token 查詢字串值 (如果有的話)。

例外狀況

例外狀況訊息通常被視為不應向用戶端顯示的敏感性資料。 根據預設,SignalR 不會將中樞方法擲回的例外狀況詳細資料傳送給用戶端。 相反地,用戶端會收到指出發生錯誤的泛型訊息。 您可以使用 EnableDetailedErrors 覆寫例外狀況訊息傳遞至用戶端 (例如在開發或測試中)。 例外狀況訊息不應公開至生產應用程式中的用戶端。

緩衝區管理

SignalR 會使用個別連線緩衝區來管理傳入和傳出訊息。 根據預設,SignalR 會將這些緩衝區限制為 32 KB。 用戶端或伺服器可以傳送的最大訊息是 32 KB。 訊息連線所耗用的最大記憶體為 32 KB。 如果您的訊息一律小於 32 KB,您可以減少限制,這會:

  • 防止用戶端傳送較大的訊息。
  • 伺服器永遠不會需要配置大型緩衝區以接受訊息。

如果您的訊息大於 32 KB,您可以增加限制。 增加此限制表示:

  • 用戶端可能會導致伺服器配置大型記憶體緩衝區。
  • 大型緩衝區的伺服器配置可能會減少並行連線數目。

傳入和傳出訊息有限制,這兩者都可以在 HttpConnectionDispatcherOptions 物件上設定,MapHub

  • ApplicationMaxBufferSize 代表伺服器緩衝區用戶端的最大位元組數目。 如果用戶端嘗試傳送大於此限制的訊息,連線可能會關閉。
  • TransportMaxBufferSize 代表伺服器可以傳送的最大位元組數目。 如果伺服器嘗試傳送大於此限制的訊息 (包括中樞方法的傳回值),則會擲回例外狀況。

將限制設定為 0 會停用限制。 移除限制可讓用戶端傳送任何大小的訊息。 傳送大型訊息的惡意用戶端可能會導致配置過多的記憶體。 記憶體使用量過多可大幅減少並行連線數目。

本文提供保護 SignalR 的相關資訊。

跨原始來源資源共用

跨原始來源資源分享 (CORS) 可用來允許瀏覽器中的跨原始來源 SignalR 連線。 如果 JavaScript 程式碼裝載於與 SignalR 應用程式不同的網域上,則必須啟用 CORS 中介軟體 ,才能讓 JavaScript 連線到 SignalR 應用程式。 只允許來自您信任或控制之網域的跨原始來源要求。 例如:

  • 您的網站裝載於 http://www.example.com
  • 您的 SignalR 應用程式裝載於 http://signalr.example.com

CORS 應該在 SignalR 應用程式中設定為只允許原始 www.example.com

如需設定 CORS 的詳細資訊,請參閱啟用跨原始來源要求 (CORS)。 SignalR需要下列 CORS 原則:

  • 允許特定的預期來源。 允許任何來源是可行的,但不是安全或建議的項目。
  • 必須允許 HTTP 方法 GETPOST
  • 必須允許認證,才能讓 cookie型黏性工作階段正常運作。 即使未使用驗證,也必須啟用它們。

不過,在 5.0 中,我們已在 TypeScript 用戶端中提供選項,以不使用認證。 只有在您知道應用程式中不需要 Cookie等認證的 100% 時,才應該使用不使用認證的選項 (cookie在使用多部伺服器進行黏性工作階段時,Azure App Service 會使用認證)。

例如,下列醒目提示的 CORS 原則可讓SignalR裝載在 上的https://example.com瀏覽器用戶端存取裝載的應用程式SignalRhttps://signalr.example.com

using SignalRChat.Hubs;

var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowSpecificOrigins,
                      policy =>
                      {
                          policy.WithOrigins("http://example.com");
                          policy.WithMethods("GET", "POST");
                          policy.AllowCredentials();
                      });
});

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

app.MapHub<ChatHub>("/chatHub");

在上一個範例中,CORS 原則會自定義為允許特定來源、方法和認證。 如需在 ASP.NET Core 中自定義 CORS 原則和中間件的詳細資訊,請參閱 CORS 中間件:具有具名原則和中間件的 CORS。

WebSocket 來源限制

CORS 所提供的保護不套用至 WebSocket。 如需 WebSocket 的原點限制,請參閱 WebSockets 原始限制

ConnectionId

如果 SignalR 伺服器或用戶端版本 ASP.NET Core 2.2 或更早版本,公開 ConnectionId 可能會導致惡意模擬。 如果 SignalR 伺服器和用戶端版本 ASP.NET Core 3.0 或更新版本,則 ConnectionToken 而非 ConnectionId 必須保密。 ConnectionToken 的目的是不會在任何 API 中公開。 很難確保較舊的 SignalR 用戶端不會連線到伺服器,因此即使您的 SignalR 伺服器版本 ASP.NET Core 3.0 或更新版本,ConnectionId 也不應該公開。

存取權杖記錄

使用 WebSockets 或伺服器傳送事件時,瀏覽器用戶端會在查詢字串中傳送存取權杖。 透過查詢字串接收存取權杖通常和使用標準 Authorization 標頭一樣安全。 一律使用 HTTPS 來確保用戶端與伺服器之間的端對端連線安全。 許多網頁伺服器都會記錄每個要求的 URL,包括查詢字串。 記錄 URL 可能會記錄存取權杖。 ASP.NET Core 預設會記錄每個要求的 URL,其中包含查詢字串。 例如:

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

如果您擔心使用伺服器記錄來記錄此資料,您可以將 Microsoft.AspNetCore.Hosting 記錄器設定為 Warning 層級或更新版本,以完全停用此記錄 (這些訊息是以 Info 層級撰寫)。 如需詳細資訊,請參閱在程式碼中套用記錄篩選規則以取得詳細資訊。 如果您仍想要記錄特定要求資訊,您可以寫入中介軟體來記錄您需要的資料,並篩選出 access_token 查詢字串值 (如果有的話)。

例外狀況

例外狀況訊息通常被視為不應向用戶端顯示的敏感性資料。 根據預設,SignalR 不會將中樞方法擲回的例外狀況詳細資料傳送給用戶端。 相反地,用戶端會收到指出發生錯誤的泛型訊息。 您可以使用 EnableDetailedErrors 覆寫例外狀況訊息傳遞至用戶端 (例如在開發或測試中)。 例外狀況訊息不應公開至生產應用程式中的用戶端。

緩衝區管理

SignalR 會使用個別連線緩衝區來管理傳入和傳出訊息。 根據預設,SignalR 會將這些緩衝區限制為 32 KB。 用戶端或伺服器可以傳送的最大訊息是 32 KB。 訊息連線所耗用的最大記憶體為 32 KB。 如果您的訊息一律小於 32 KB,您可以減少限制,這會:

  • 防止用戶端傳送較大的訊息。
  • 伺服器永遠不會需要配置大型緩衝區以接受訊息。

如果您的訊息大於 32 KB,您可以增加限制。 增加此限制表示:

  • 用戶端可能會導致伺服器配置大型記憶體緩衝區。
  • 大型緩衝區的伺服器配置可能會減少並行連線數目。

傳入和傳出訊息有限制,這兩者都可以在 HttpConnectionDispatcherOptions 物件上設定,MapHub

  • ApplicationMaxBufferSize 代表伺服器緩衝區用戶端的最大位元組數目。 如果用戶端嘗試傳送大於此限制的訊息,連線可能會關閉。
  • TransportMaxBufferSize 代表伺服器可以傳送的最大位元組數目。 如果伺服器嘗試傳送大於此限制的訊息 (包括中樞方法的傳回值),則會擲回例外狀況。

將限制設定為 0 會停用限制。 移除限制可讓用戶端傳送任何大小的訊息。 傳送大型訊息的惡意用戶端可能會導致配置過多的記憶體。 記憶體使用量過多可大幅減少並行連線數目。

本文提供保護 SignalR 的相關資訊。

跨原始來源資源共用

跨原始來源資源分享 (CORS) 可用來允許瀏覽器中的跨原始來源 SignalR 連線。 如果 JavaScript 程式碼裝載於與 SignalR 應用程式不同的網域上,則必須啟用 CORS 中介軟體 ,才能讓 JavaScript 連線到 SignalR 應用程式。 只允許來自您信任或控制之網域的跨原始來源要求。 例如:

  • 您的網站裝載於 http://www.example.com
  • 您的 SignalR 應用程式裝載於 http://signalr.example.com

CORS 應該在 SignalR 應用程式中設定為只允許原始 www.example.com

如需設定 CORS 的詳細資訊,請參閱啟用跨原始來源要求 (CORS)。 SignalR需要下列 CORS 原則:

  • 允許特定的預期來源。 允許任何來源是可行的,但不是安全或建議的項目。
  • 必須允許 HTTP 方法 GETPOST
  • 必須允許認證,才能讓 cookie型黏性工作階段正常運作。 即使未使用驗證,也必須啟用它們。

不過,在 5.0 中,我們已在 TypeScript 用戶端中提供選項,以不使用認證。 只有在您知道應用程式中不需要 Cookie等認證的 100% 時,才應該使用不使用認證的選項 (cookie在使用多部伺服器進行黏性工作階段時,Azure App Service 會使用認證)。

例如,下列醒目提示的 CORS 原則可讓SignalR裝載在 上的https://example.com瀏覽器用戶端存取裝載的應用程式SignalRhttps://signalr.example.com

using SignalRChat.Hubs;

var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowSpecificOrigins,
                      policy =>
                      {
                          policy.WithOrigins("http://example.com");
                          policy.WithMethods("GET", "POST");
                          policy.AllowCredentials();
                      });
});

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

app.MapHub<ChatHub>("/chatHub");

在上一個範例中,CORS 原則會自定義為允許特定來源、方法和認證。 如需在 ASP.NET Core 中自定義 CORS 原則和中間件的詳細資訊,請參閱 CORS 中間件:具有具名原則和中間件的 CORS。

WebSocket 來源限制

CORS 所提供的保護不套用至 WebSocket。 如需 WebSocket 的原點限制,請參閱 WebSockets 原始限制

ConnectionId

如果 SignalR 伺服器或用戶端版本 ASP.NET Core 2.2 或更早版本,公開 ConnectionId 可能會導致惡意模擬。 如果 SignalR 伺服器和用戶端版本 ASP.NET Core 3.0 或更新版本,則 ConnectionToken 而非 ConnectionId 必須保密。 ConnectionToken 的目的是不會在任何 API 中公開。 很難確保較舊的 SignalR 用戶端不會連線到伺服器,因此即使您的 SignalR 伺服器版本 ASP.NET Core 3.0 或更新版本,ConnectionId 也不應該公開。

存取權杖記錄

使用 WebSockets 或伺服器傳送事件時,瀏覽器用戶端會在查詢字串中傳送存取權杖。 透過查詢字串接收存取權杖通常和使用標準 Authorization 標頭一樣安全。 一律使用 HTTPS 來確保用戶端與伺服器之間的端對端連線安全。 許多網頁伺服器都會記錄每個要求的 URL,包括查詢字串。 記錄 URL 可能會記錄存取權杖。 ASP.NET Core 預設會記錄每個要求的 URL,其中包含查詢字串。 例如:

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

如果您擔心使用伺服器記錄來記錄此資料,您可以將 Microsoft.AspNetCore.Hosting 記錄器設定為 Warning 層級或更新版本,以完全停用此記錄 (這些訊息是以 Info 層級撰寫)。 如需詳細資訊,請參閱在程式碼中套用記錄篩選規則以取得詳細資訊。 如果您仍想要記錄特定要求資訊,您可以寫入中介軟體來記錄您需要的資料,並篩選出 access_token 查詢字串值 (如果有的話)。

例外狀況

例外狀況訊息通常被視為不應向用戶端顯示的敏感性資料。 根據預設,SignalR 不會將中樞方法擲回的例外狀況詳細資料傳送給用戶端。 相反地,用戶端會收到指出發生錯誤的泛型訊息。 您可以使用 EnableDetailedErrors 覆寫例外狀況訊息傳遞至用戶端 (例如在開發或測試中)。 例外狀況訊息不應公開至生產應用程式中的用戶端。

緩衝區管理

SignalR 會使用個別連線緩衝區來管理傳入和傳出訊息。 根據預設,SignalR 會將這些緩衝區限制為 32 KB。 用戶端或伺服器可以傳送的最大訊息是 32 KB。 訊息連線所耗用的最大記憶體為 32 KB。 如果您的訊息一律小於 32 KB,您可以減少限制,這會:

  • 防止用戶端傳送較大的訊息。
  • 伺服器永遠不會需要配置大型緩衝區以接受訊息。

如果您的訊息大於 32 KB,您可以增加限制。 增加此限制表示:

  • 用戶端可能會導致伺服器配置大型記憶體緩衝區。
  • 大型緩衝區的伺服器配置可能會減少並行連線數目。

傳入和傳出訊息有限制,這兩者都可以在 HttpConnectionDispatcherOptions 物件上設定,MapHub

  • ApplicationMaxBufferSize 代表伺服器緩衝區用戶端的最大位元組數目。 如果用戶端嘗試傳送大於此限制的訊息,連線可能會關閉。
  • TransportMaxBufferSize 代表伺服器可以傳送的最大位元組數目。 如果伺服器嘗試傳送大於此限制的訊息 (包括中樞方法的傳回值),則會擲回例外狀況。

將限制設定為 0 會停用限制。 移除限制可讓用戶端傳送任何大小的訊息。 傳送大型訊息的惡意用戶端可能會導致配置過多的記憶體。 記憶體使用量過多可大幅減少並行連線數目。

本文提供保護 SignalR 的相關資訊。

跨原始來源資源共用

跨原始來源資源分享 (CORS) 可用來允許瀏覽器中的跨原始來源 SignalR 連線。 如果 JavaScript 程式碼裝載於與 SignalR 應用程式不同的網域上,則必須啟用 CORS 中介軟體 ,才能讓 JavaScript 連線到 SignalR 應用程式。 只允許來自您信任或控制之網域的跨原始來源要求。 例如:

  • 您的網站裝載於 http://www.example.com
  • 您的 SignalR 應用程式裝載於 http://signalr.example.com

CORS 應該在 SignalR 應用程式中設定為只允許原始 www.example.com

如需設定 CORS 的詳細資訊,請參閱啟用跨原始來源要求 (CORS)。 SignalR需要下列 CORS 原則:

  • 允許特定的預期來源。 允許任何來源是可行的,但不是安全或建議的項目。
  • 必須允許 HTTP 方法 GETPOST
  • 必須允許認證,才能讓 cookie型黏性工作階段正常運作。 即使未使用驗證,也必須啟用它們。

不過,在 5.0 中,我們已在 TypeScript 用戶端中提供選項,以不使用認證。 只有在您知道應用程式中不需要 Cookie等認證的 100% 時,才應該使用不使用認證的選項 (cookie在使用多部伺服器進行黏性工作階段時,Azure App Service 會使用認證)。

例如,下列 CORS 原則允許裝載在 https://example.com 上的 SignalR 瀏覽器用戶端存取裝載於 https://signalr.example.com 上的 SignalR 應用程式:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... other middleware ...

    // Make sure the CORS middleware is ahead of SignalR.
    app.UseCors(builder =>
    {
        builder.WithOrigins("https://example.com")
            .AllowAnyHeader()
            .WithMethods("GET", "POST")
            .AllowCredentials();
    });

    // ... other middleware ...
    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHub<ChatHub>("/chathub");
    });

    // ... other middleware ...
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... other middleware ...

    // Make sure the CORS middleware is ahead of SignalR.
    app.UseCors(builder =>
    {
        builder.WithOrigins("https://example.com")
            .AllowAnyHeader()
            .WithMethods("GET", "POST")
            .AllowCredentials();
    });

    // ... other middleware ...

    app.UseSignalR(routes =>
    {
        routes.MapHub<ChatHub>("/chathub");
    });

    // ... other middleware ...
}

WebSocket 來源限制

CORS 所提供的保護不套用至 WebSocket。 如需 WebSocket 的原點限制,請參閱 WebSockets 原始限制

CORS 所提供的保護不套用至 WebSocket。 瀏覽器會:

  • 執行 CORS 的事前要求。
  • 進行 WebSocket 要求時,採用 Access-Control 標頭中所指定的限制。

不過,瀏覽器會在發出 WebSocket 要求時,傳送 Origin 標頭。 應設定應用程式驗證這些標頭,以確保只允許來自預期來源的 WebSocket。

在 ASP.NET Core 2.1 和更新版本中,您可以使用放在 UseSignalR之前的自訂中介軟體,以及 Configure 中的驗證中介軟體來達成標頭驗證:


// In Startup, add a static field listing the allowed Origin values:
private static readonly HashSet<string> _allowedOrigins = new HashSet<string>()
{
    // Add allowed origins here. For example:
    "https://www.mysite.com",
    "https://mysite.com",
};

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... other middleware ...

    // Validate Origin header on WebSocket requests to prevent unexpected cross-site 
    // WebSocket requests.
    app.Use((context, next) =>
    {
        // Check for a WebSocket request.
        if (string.Equals(context.Request.Headers["Upgrade"], "websocket"))
        {
            var origin = context.Request.Headers["Origin"];

            // If there is an origin header, and the origin header doesn't match 
            // an allowed value:
            if (!string.IsNullOrEmpty(origin) && !_allowedOrigins.Contains(origin))
            {
                // The origin is not allowed, reject the request
                context.Response.StatusCode = (int) HttpStatusCode.Forbidden;
                return Task.CompletedTask;
            }
        }

        // The request is a valid Origin or not a WebSocket request, so continue.
        return next();
    });

    // ... other middleware ...

    app.UseSignalR(routes =>
    {
        routes.MapHub<ChatHub>("/chathub");
    });

    // ... other middleware ...
}

注意

因為 Origin 由用戶端控制,所以和 Referer 標頭一樣可能受到偽造。 這些標頭不得做為驗證機制。

ConnectionId

如果 SignalR 伺服器或用戶端版本 ASP.NET Core 2.2 或更早版本,公開 ConnectionId 可能會導致惡意模擬。 如果 SignalR 伺服器和用戶端版本 ASP.NET Core 3.0 或更新版本,則 ConnectionToken 而非 ConnectionId 必須保密。 ConnectionToken 的目的是不會在任何 API 中公開。 很難確保較舊的 SignalR 用戶端不會連線到伺服器,因此即使您的 SignalR 伺服器版本 ASP.NET Core 3.0 或更新版本,ConnectionId 也不應該公開。

存取權杖記錄

使用 WebSockets 或伺服器傳送事件時,瀏覽器用戶端會在查詢字串中傳送存取權杖。 透過查詢字串接收存取權杖通常和使用標準 Authorization 標頭一樣安全。 一律使用 HTTPS 來確保用戶端與伺服器之間的端對端連線安全。 許多網頁伺服器都會記錄每個要求的 URL,包括查詢字串。 記錄 URL 可能會記錄存取權杖。 ASP.NET Core 預設會記錄每個要求的 URL,其中包含查詢字串。 例如:

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

如果您擔心使用伺服器記錄來記錄此資料,您可以將 Microsoft.AspNetCore.Hosting 記錄器設定為 Warning 層級或更新版本,以完全停用此記錄 (這些訊息是以 Info 層級撰寫)。 如需詳細資訊,請參閱在程式碼中套用記錄篩選規則以取得詳細資訊。 如果您仍想要記錄特定要求資訊,您可以寫入中介軟體來記錄您需要的資料,並篩選出 access_token 查詢字串值 (如果有的話)。

例外狀況

例外狀況訊息通常被視為不應向用戶端顯示的敏感性資料。 根據預設,SignalR 不會將中樞方法擲回的例外狀況詳細資料傳送給用戶端。 相反地,用戶端會收到指出發生錯誤的泛型訊息。 您可以使用 EnableDetailedErrors 覆寫例外狀況訊息傳遞至用戶端 (例如在開發或測試中)。 例外狀況訊息不應公開至生產應用程式中的用戶端。

緩衝區管理

SignalR 會使用個別連線緩衝區來管理傳入和傳出訊息。 根據預設,SignalR 會將這些緩衝區限制為 32 KB。 用戶端或伺服器可以傳送的最大訊息是 32 KB。 訊息連線所耗用的最大記憶體為 32 KB。 如果您的訊息一律小於 32 KB,您可以減少限制,這會:

  • 防止用戶端傳送較大的訊息。
  • 伺服器永遠不會需要配置大型緩衝區以接受訊息。

如果您的訊息大於 32 KB,您可以增加限制。 增加此限制表示:

  • 用戶端可能會導致伺服器配置大型記憶體緩衝區。
  • 大型緩衝區的伺服器配置可能會減少並行連線數目。

傳入和傳出訊息有限制,這兩者都可以在 HttpConnectionDispatcherOptions 物件上設定,MapHub

  • ApplicationMaxBufferSize 代表伺服器緩衝區用戶端的最大位元組數目。 如果用戶端嘗試傳送大於此限制的訊息,連線可能會關閉。
  • TransportMaxBufferSize 代表伺服器可以傳送的最大位元組數目。 如果伺服器嘗試傳送大於此限制的訊息 (包括中樞方法的傳回值),則會擲回例外狀況。

將限制設定為 0 會停用限制。 移除限制可讓用戶端傳送任何大小的訊息。 傳送大型訊息的惡意用戶端可能會導致配置過多的記憶體。 記憶體使用量過多可大幅減少並行連線數目。