ASP.NET Core BlazorSignalR útmutatója

Ez a cikk bemutatja, hogyan konfigurálhatja és kezelheti SignalR kapcsolatokat Blazor alkalmazásokban.

Az ASP.NET Core SignalR konfigurációval kapcsolatos általános útmutatásért tekintse meg a dokumentáció ASP.NET Core SignalRterületének áttekintés témaköreit, különösen az ASP.NET Core SignalR konfigurációt.

A kiszolgálóoldali alkalmazások a ASP.NET Core SignalR használatával kommunikálnak a böngészővel. SignalRüzemeltetési és skálázási feltételei vonatkoznak a kiszolgálóoldali alkalmazásokra.

Blazor akkor működik a legjobban, ha a WebSocketeket SignalR átvitelként használja az alacsonyabb késés, megbízhatóság és biztonságimiatt. A hosszú lekérdezést akkor használja a SignalR, ha a WebSockets nem érhető el, vagy ha az alkalmazás kifejezetten a Long Polling használatára van konfigurálva.

Azure SignalR Szolgáltatás állapotalapú újracsatlakozással

Az Azure SignalR szolgáltatás SDK-val 1.26.1- vagy újabb verzióval támogatja SignalR állapotalapú újracsatlakozás (WithStatefulReconnect).

WebSocket-tömörítés interaktív kiszolgálóösszetevőkhöz

Alapértelmezés szerint az interaktív kiszolgáló összetevői:

• Tömörítés engedélyezése WebSocket-kapcsolatokhoz . DisableWebSocketCompression (alapértelmezett: false) szabályozza a WebSocket tömörítését.

• Fogadjon el egy frame-ancestors tartalombiztonsági szabályzatot (CSP) úgy, hogy az utasítássort az alapértelmezett 'self' értékre állítja, ami csak akkor engedélyezi az alkalmazás beágyazását az eredeti <iframe> forrásba, ahonnan az alkalmazás kiszolgálásra kerül, ha a tömörítés engedélyezett, vagy ha a WebSocket-környezet konfigurációja megadott.

Alapértelmezett frame-ancestors CSP megváltoztatható a ContentSecurityFrameAncestorsPolicy értékének null módosításával, ha a CSP-t központosított módon szeretné konfigurálni, vagy 'none' az is lehetséges, hogy még szigorúbb szabályzatot alkalmaz. Ha a frame-ancestors CSP központosított módon van kezelve, ügyelni kell arra, hogy az első dokumentum megjelenítésekor szabályzatot alkalmazzon. Nem javasoljuk a szabályzat teljes eltávolítását, mivel az sebezhetővé teszi az alkalmazást a támadással szemben. További információ: Tartalombiztonsági szabályzat kényszerítése ASP.NET Core-hoz Blazor és az MDN CSP útmutatója.

A ConfigureWebSocketAcceptContext használja a WebSocketAcceptContext konfigurálására a szerver komponensei által használt WebSocket-kapcsolatokat. Alapértelmezés szerint a rendszer egy olyan házirendet alkalmaz, amely lehetővé teszi a tömörítést, és beállít egy CSP-t a ContentSecurityFrameAncestorsPolicy definiált keretelődeihez.

Használati példák:

Tiltsa le a tömörítést a DisableWebSocketCompressiontruebeállításával, amely csökkenti az alkalmazás biztonsági rését a támadásához, de a teljesítmény csökkenését eredményezheti:

builder.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode(o => o.DisableWebSocketCompression = true)

Ha a tömörítés engedélyezve van, konfiguráljon egy szigorúbb frame-ancestors CSP-t 'none' (egyszeres idézőjelet szükséges), amely lehetővé teszi a WebSocket tömörítést, de megakadályozza, hogy a böngészők beágyazhassák az alkalmazást egy <iframe> keretbe.

builder.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode(o => o.ContentSecurityFrameAncestorsPolicy = "'none'")

Ha a tömörítés engedélyezve van, távolítsa el a frame-ancestors CSP-t a ContentSecurityFrameAncestorsPolicynullbeállításával. Ez a forgatókönyv csak olyan alkalmazások esetében ajánlott, amelyek központi állítják be a CSP-t:

builder.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode(o => o.ContentSecurityFrameAncestorsPolicy = null)

Fontos

A böngészők több CSP-fejlécből származó CSP-irányelveket alkalmaznak a legszigorúbb szabályzatirányelv-érték használatával. Ezért a fejlesztők nem adhatnak hozzá gyengébb frame-ancestors szabályzatot, mint 'self' szándékosan vagy véletlenül.

A ContentSecurityFrameAncestorsPolicy átadott szöveges értéken egyszeres idézőjelek szükségesek:

❌ nem támogatott értékek:none, self

✔️ támogatott értékek:'none', 'self'

A további lehetőségek közé tartozik egy vagy több host forrás és séma forrás megadása.

A biztonsági következményekről a ASP.NET Core Blazor interaktív kiszolgálóoldali renderelési veszélyforrások elhárítására vonatkozó útmutatóban olvashat. További információ: Tartalombiztonsági szabályzat kényszerítése ASP.NET Core Blazor és CSP esetén: frame-ancestors (MDN-dokumentáció).

Válasz tömörítés letiltása a Hot Reload esetén.

A Hot Reload használata során tiltsa le a Response Compression Middleware-t a környezetben. Függetlenül attól, hogy egy projektsablon alapértelmezett kódját használja-e, mindig hívja meg UseResponseCompression először a kérésfeldolgozási folyamatban.

A Program fájlban:

if (!app.Environment.IsDevelopment())
{
    app.UseResponseCompression();
}

Ügyféloldali SignalR hitelesítési kérés egyeztetése eltérő eredetű források között

Ez a szakasz azt ismerteti, hogyan konfigurálhatja SignalRmögöttes ügyfelet hitelesítő adatok, például cookie-k vagy HTTP-hitelesítési fejlécek küldéséhez.

A SetBrowserRequestCredentials használatával állítsa be a Include-et a forrásközi fetch-kérelmekhez.

IncludeRequestCredentialsMessageHandler.cs:

using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Components.WebAssembly.Http;

public class IncludeRequestCredentialsMessageHandler : DelegatingHandler
{
    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        request.SetBrowserRequestCredentials(BrowserRequestCredentials.Include);
        return base.SendAsync(request, cancellationToken);
    }
}

Központi kapcsolat létrehozása esetén rendelje hozzá a HttpMessageHandler a HttpMessageHandlerFactory beállításhoz:

private HubConnectionBuilder? hubConnection;

...

hubConnection = new HubConnectionBuilder()
    .WithUrl(new Uri(Navigation.ToAbsoluteUri("/chathub")), options =>
    {
        options.HttpMessageHandlerFactory = innerHandler => 
            new IncludeRequestCredentialsMessageHandler { InnerHandler = innerHandler };
    }).Build();

Az előző példa a hub kapcsolati URL-címét az abszolút URI-címre konfigurálja /chathub. Az URI egy sztringen keresztül is beállítható, például https://signalr.example.com, vagy konfigurációval. Navigation egy injektált NavigationManager.

További információkért lásd ASP.NET Core SignalR konfiguráció.

Ügyféloldali renderelés

Ha az előrendelés konfigurálva van, az előrendelés a kiszolgálóhoz való ügyfélkapcsolat létrehozása előtt történik. További információ: ASP.NET Core Blazor előre beállított állapotmegőrzés.

Előre beállított állapotméret és SignalR üzenetméretkorlát

A nagy előrerendelt állapotméret meghaladhatja BlazorSignalR kapcsolatcsoport üzenetméretkorlátját, ami a következőket eredményezi:

• A SignalR áramkör nem tud inicializálni egy hibával az ügyfélen: Circuit host not initialized.
• Az ügyfél újracsatlakozási felhasználói felülete akkor jelenik meg, ha a kapcsolatcsoport meghibásodik. A helyreállítás nem lehetséges.

A probléma megoldásához használja vagy a , vagy a alábbi módszerek egyikét:

• Csökkentse az előre beállított állapotba helyezendő adatok mennyiségét.
• Növelje az SignalR üzenet méretkorlátját. FIGYELMEZTETÉS: A korlát növelése növelheti a szolgáltatásmegtagadási (DoS-) támadások kockázatát.

További ügyféloldali erőforrások

• Tegye biztonságossá a SignalR központot
• ASP.NET Core SignalR áttekintése
• ASP.NET Core SignalR konfiguráció
• Blazor minták a GitHub adattárból (dotnet/blazor-samples) (hogyan lehet letölteni)

Munkamenet-affinitás (ragadós munkamenetek) használata kiszolgálóoldali webfarm-üzemeltetéshez

Ha egynél több háttérkiszolgáló van használatban, az alkalmazásnak munkamenet-affinitást kell implementálnia, más néven ragadós munkameneteket. A munkamenet-affinitás biztosítja, hogy az ügyfél kapcsolatcsoportja újra csatlakozik ugyanahhoz a kiszolgálóhoz, ha megszakad a kapcsolat, ami azért fontos, mert az ügyfél állapota csak annak a kiszolgálónak a memóriájában van, amely először létrehozta az ügyfél kapcsolatcsoportját.

A következő hibát egy olyan alkalmazás okozza, amely nem engedélyezte a munkamenet-affinitást egy webfarmban:

Uncaught (in promise) Error: Invocation canceled due to the underlying connection being closed.

További információért az Azure App Service-üzemeltetéssel kapcsolatos munkamenet-affinitásról lásd: Blazor.

Azure SignalR Szolgáltatás

Az opcionális Azure SignalR Service- az alkalmazás SignalR központjával együtt működik a kiszolgálóoldali alkalmazások nagy számú egyidejű kapcsolatra való skálázásához. Emellett a szolgáltatás globális elérése és a nagy teljesítményű adatközpontok jelentősen elősegítik a földrajzi hely miatti késés csökkentését.

A szolgáltatás nem szükséges az Azure App Service-ben vagy az Azure Container Appsben üzemeltetett Blazor alkalmazásokhoz, de más üzemeltetési környezetekben is hasznos lehet:

• A kapcsolatok kiterjesztésének megkönnyítése.
• Globális disztribúció kezelése.

További információ: Gazdagép és ASP.NET Core kiszolgálóoldali Blazor alkalmazások üzembe helyezése.

Kiszolgálóoldali kör-kezelő beállításai

Konfigurálja az áramkört a CircuitOptions-val. Az alapértelmezett értékeket a referenciaforrás-ban tekintse meg.

Jegyzet

A .NET referenciaforrásra mutató dokumentációs hivatkozások általában betöltik az adattár alapértelmezett ágát, amely a .NET következő kiadásának aktuális fejlesztését jelöli. Egy adott kiadás címkéjének kiválasztásához használja a Ágak vagy címkék legördülő listát. További információ: A ASP.NET Core-forráskód (dotnet/AspNetCore.Docs #26205) verziócímkéjének kiválasztása.

Olvassa el vagy állítsa be az opciókat a Program fájlban egy opciós delegálttal AddInteractiveServerComponents-en. A {OPTION} helyőrző jelöli a beállítást, a {VALUE} helyőrző pedig az érték.

A Program fájlban:

builder.Services.AddRazorComponents().AddInteractiveServerComponents(options =>
{
    options.{OPTION} = {VALUE};
});

A HubConnectionContextkonfigurálásához a HubConnectionContextOptions-et a AddHubOptions-vel használja. A központi kapcsolat környezeti beállításainak alapértelmezései megtekinthetők a referenciaforrásban. A SignalR dokumentációjában található beállításleírásokat a ASP.NET Core SignalR konfigurációscímű cikkben találja. A {OPTION} helyőrző jelöli a beállítást, a {VALUE} helyőrző pedig az érték.

Jegyzet

A .NET referenciaforrásra mutató dokumentációs hivatkozások általában betöltik az adattár alapértelmezett ágát, amely a .NET következő kiadásának aktuális fejlesztését jelöli. Egy adott kiadás címkéjének kiválasztásához használja a Ágak vagy címkék legördülő listát. További információ: A ASP.NET Core-forráskód (dotnet/AspNetCore.Docs #26205) verziócímkéjének kiválasztása.

A Program fájlban:

builder.Services.AddRazorComponents().AddInteractiveServerComponents().AddHubOptions(options =>
{
    options.{OPTION} = {VALUE};
});

Figyelmeztetés

A MaximumReceiveMessageSize alapértelmezett értéke 32 KB. Az érték növelése növelheti szolgáltatásmegtagadási (DoS-) támadások kockázatát.

Blazor az MaximumParallelInvocationsPerClient-re támaszkodik, amely 1-re van állítva, ami az alapértelmezett érték. További információért lásd: MaximumParallelInvocationsPerClient > 1, amely megszakítja a fájlfeltöltést a Blazor Server módban (dotnet/aspnetcore #53951).

A memóriakezeléssel kapcsolatos információkért lásd: Memória kezelése az üzembe helyezett ASP.NET Core kiszolgálóoldali Blazor alkalmazásokban.

Blazor központ beállításai

Konfiguráljon MapBlazorHub beállításokat a HttpConnectionDispatcherOptions központ Blazor vezérléséhez. Tekintse meg a központi kapcsolati diszpécser beállításainak alapértelmezett beállításait referenciaforrás. A {OPTION} helyőrző jelöli a beállítást, a {VALUE} helyőrző pedig az érték.

Jegyzet

A .NET referenciaforrásra mutató dokumentációs hivatkozások általában betöltik az adattár alapértelmezett ágát, amely a .NET következő kiadásának aktuális fejlesztését jelöli. Egy adott kiadás címkéjének kiválasztásához használja a Ágak vagy címkék legördülő listát. További információ: A ASP.NET Core-forráskód (dotnet/AspNetCore.Docs #26205) verziócímkéjének kiválasztása.

Helyezze el a app.MapBlazorHub hívást a app.MapRazorComponents hívás után az alkalmazás Program fájljában.

app.MapBlazorHub(options =>
{
    options.{OPTION} = {VALUE};
});

A AddInteractiveServerRenderMode által használt MapBlazorHub központ konfigurálása AmbiguousMatchExceptionhibával meghiúsul.

Microsoft.AspNetCore.Routing.Matching.AmbiguousMatchException: The request matched multiple endpoints.

A .NET 8/9-et célzó alkalmazások problémájának megoldásához kövesse az alábbi megközelítést.

A fájl tetején Program adjon hozzá egy utasítást using a következőhöz Microsoft.AspNetCore.Http.Connections:

using Microsoft.AspNetCore.Http.Connections;

A MapRazorComponents meghívott helyhez a következő végpontkonvenciát kell a következőhöz láncra fűzni RazorComponentsEndpointConventionBuilder:

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .Add(e =>
    {
        var metadata = e.Metadata;
        var dispatcherOptions = metadata.OfType<HttpConnectionDispatcherOptions>().FirstOrDefault();

        if (dispatcherOptions != null)
        {
            dispatcherOptions.CloseOnAuthenticationExpiration = true;
        }
    });

További információ:

• A MapBlazorHub-konfiguráció a NET8-ben kivételt okoz, miszerint a kérés több végponthoz illeszkedik (dotnet/aspnetcore #51698)
• Ha több blazor belépési pontot próbál leképelni a MapBlazorHubbal, az nem egyértelmű útvonalhibát okoz. Ez működött az net7 (dotnet/aspnetcore #52156)
• [Blazor] Hozzáférés biztosítása az alapul szolgálóhoz SignalR HttpConnectionDispatcherOptions in AddInteractiveServerRenderMode (dotnet/aspnetcore #63520)

A fogadási üzenetek maximális mérete

Ez a szakasz csak azokra a projektekre vonatkozik, amelyek SignalRimplementálnak.

A központi metódusokhoz engedélyezett maximális bejövő SignalR üzenetméretet a HubOptions.MaximumReceiveMessageSize korlátozza (alapértelmezés: 32 KB). SignalR MaximumReceiveMessageSize-nél nagyobb üzenetek hibát jeleznek. A keretrendszer nem korlátozza az SignalR-üzenetek méretét a központtól az ügyfélig.

Ha a SignalR naplózás nincs beállítva Hibakeresés vagy Nyomkövetésszintre, akkor az üzenetméret-hiba csak a böngésző fejlesztői eszközeinek konzolján jelenik meg.

Hiba: A kapcsolat megszakadt a következő hibával: Hiba: A kiszolgáló hibát adott vissza a bezáráskor: A kapcsolat hiba miatt lezárult." hibaüzenet jelenik meg.

Ha a kiszolgálóoldali naplózás hibakeresésre SignalR van állítva, a kiszolgálóoldali naplózás megjelenít egy üzenetméret-hibát.

appsettings.Development.json:

{
  "DetailedErrors": true,
  "Logging": {
    "LogLevel": {
      ...
      "Microsoft.AspNetCore.SignalR": "Debug"
    }
  }
}

Hiba:

System.IO.InvalidDataException: Túllépte a 32768B maximális üzenetméretet. Az üzenet mérete konfigurálható az AddHubOptionsban.

Az egyik módszer a korlát növelését foglalja magában a MaximumReceiveMessageSize fájlban Program beállításával. Az alábbi példa 64 KB-ra állítja a fogadási üzenetek maximális méretét:

builder.Services.AddRazorComponents().AddInteractiveServerComponents()
    .AddHubOptions(options => options.MaximumReceiveMessageSize = 64 * 1024);

A SignalR bejövő üzenetek méretkorlátjának növeléséhez több kiszolgálói erőforrásra van szükség, és növeli a szolgáltatásmegtagadási (DoS-) támadásokkockázatát. Emellett, ha nagy mennyiségű adatot olvas be a memóriába sztringként vagy bájttömbként, az olyan foglalásokat eredményezhet, amelyek rosszul illeszkednek a szemétgyűjtő működéséhez, ami további teljesítménycsökkenéseket eredményez.

A nagy méretű adatok olvasásának jobb lehetősége, ha a tartalmat kisebb tömbökben küldi el, és feldolgozza őket Stream-ként. Ez használható nagy JavaScript (JS) interoperációs JSON terhelések olvasásakor, vagy ha JS interop adatok nyers bájtként állnak rendelkezésre. Az InputFile összetevőhözhasonló technikákat használó kiszolgálóoldali alkalmazásokban történő nagy bináris hasznos adatok küldését bemutató példáért tekintse meg a Bináris küldés mintaalkalmazás és a BlazorInputLargeTextArea összetevőmintacímű témakört.

Jegyzet

A .NET referenciaforrásra mutató dokumentációs hivatkozások általában betöltik az adattár alapértelmezett ágát, amely a .NET következő kiadásának aktuális fejlesztését jelöli. Egy adott kiadás címkéjének kiválasztásához használja a Ágak vagy címkék legördülő listát. További információ: A ASP.NET Core-forráskód (dotnet/AspNetCore.Docs #26205) verziócímkéjének kiválasztása.

A SignalR felett nagy mennyiségű adatokat feldolgozó űrlapok közvetlenül is használhatják a streaming JS interopot. További információ: .NET-metódusok meghívása JavaScript-függvényekből a ASP.NET Core Blazor. Az <textarea> adatokat a kiszolgálóra streamelő űrlapok példájáért lásd: ASP.NET Core Blazor űrlapok hibaelhárítása a.

A nagy mennyiségű adatot átadó kód fejlesztésekor vegye figyelembe az alábbi útmutatást:

• Használja ki a natív streamelési JS interop támogatást a bejövő üzenetek SignalR méretkorlátnál nagyobb adatok átviteléhez:
  • JavaScript-függvények meghívása .NET-metódusokból a ASP.NET Core Blazor
  • .NET-metódusok meghívása JavaScript-függvényekből a ASP.NET Core Blazor
  • Űrlap terhelési példája: ASP.NET Core űrlapok hibaelhárítása Blazor
• Általános tippek:
  • Ne foglalja le a nagyméretű objektumokat a JS és a C# kódban.
  • A folyamat befejeztével vagy megszakításával szabadíthatja fel a felhasznált memóriát.
  • Biztonsági okokból a következő további követelmények érvényesítése:
    • Deklarálja az átadható maximális fájl- vagy adatméretet.
    • Deklarálja az ügyfélről a kiszolgálóra való minimális feltöltési sebességet.
  • Miután a kiszolgáló megkapta az adatokat, az adatok a következőek lehetnek:
    • Ideiglenesen tárolódik egy memóriapufferben, amíg az összes szegmenst össze nem gyűjti.
    • Azonnal fogyasztandó. Az adatok például azonnal tárolhatók egy adatbázisban, vagy lemezre írhatók az egyes szegmensek fogadásakor.

Blazor kiszolgálóoldali hub végpontútvonalának konfigurációja

A Program fájlban hívja meg a MapBlazorHub-et, hogy a BlazorHub-at az alkalmazás alapértelmezett elérési útjára képezze le. A Blazor szkript (blazor.*.js) automatikusan a MapBlazorHubáltal létrehozott végpontra mutat.

A kiszolgálóoldali kapcsolat állapotának tükrözése a felhasználói felületen

Ha az ügyfél elveszett kapcsolatot észlel a kiszolgálóval, egy alapértelmezett felhasználói felület jelenik meg a felhasználó számára, miközben az ügyfél megpróbál újracsatlakozni:

Ha az újracsatlakozás sikertelen, a rendszer arra utasítja a felhasználót, hogy próbálkozzon újra vagy töltse be újra a lapot:

Ha az újracsatlakozás sikeres, a felhasználói állapot gyakran elvész. Bármely összetevőhöz hozzáadhat egyéni kódot a felhasználói állapot kapcsolati hibák közötti mentéséhez és újratöltéséhez. További információ: ASP.NET Core-állapotkezelés Blazor áttekintése és ASP.NET Core-kiszolgálóoldali Blazor állapotkezelés.

Az újrakapcsolódási állapotot nyomon követő felhasználói felületi elemek létrehozásához az alábbi táblázat ismerteti:

• Olyan components-reconnect-* CSS osztályok (Css-osztály oszlop), amelyeket Blazor beállít vagy eltávolít egy id-ös components-reconnect-modal elemen.
• Egy components-reconnect-state-changed esemény (Esemény oszlop), amely az újracsatlakozási állapot változását jelzi.

CSS-osztály	Esemény	Azt jelzi...
components-reconnect-show	show	Megszakadt a kapcsolat. Az ügyfél megpróbál újracsatlakozni. Megjelenik az újracsatlakozási mód.
components-reconnect-hide	hide	A rendszer újra létrehoz egy aktív kapcsolatot a kiszolgálóval. Az újracsatlakozási modell bezárult.
components-reconnect-retrying	retrying	Az ügyfél megpróbál újracsatlakozni.
components-reconnect-failed	failed	Az újracsatlakozás valószínűleg hálózati hiba miatt meghiúsult.
components-reconnect-rejected	rejected	Az újracsatlakozás elutasítva.

Ha components-reconnect-state-changed újracsatlakozási állapota failed, hívja meg a Blazor.reconnect() JavaScriptben ahhoz, hogy megkísérelje az újracsatlakozást.

Ha az újracsatlakozási állapot módosulása rejected, a szerver elérhető volt, de elutasította a kapcsolatot, és a felhasználó állapota elveszett a szerveren. Az alkalmazás újratöltéséhez hívja meg a location.reload()-t a JavaScript nyelvben. Ez a kapcsolati állapot a következő esetekben léphet fel:

• Összeomlás történik a kiszolgálóoldali kapcsolatcsoportban.
• A kliens elég hosszú ideig van leválasztva ahhoz, hogy a kiszolgáló elvesse a felhasználó állapotát. A rendszer megsemmisíti a felhasználó összetevőinek példányait.
• A kiszolgáló újraindul, vagy az alkalmazás feldolgozó folyamata újraindul.

A fejlesztő hozzáad egy eseményfigyelőt az újracsatlakozási modális elemhez az újrakapcsolódási állapot változásainak figyeléséhez és azokra való reagáláshoz, ahogyan az alábbi példában látható:

const reconnectModal = document.getElementById("components-reconnect-modal");
reconnectModal.addEventListener("components-reconnect-state-changed", 
  handleReconnectStateChanged);

function handleReconnectStateChanged(event) {
  if (event.detail.state === "show") {
    reconnectModal.showModal();
  } else if (event.detail.state === "hide") {
    reconnectModal.close();
  } else if (event.detail.state === "failed") {
    Blazor.reconnect();
  } else if (event.detail.state === "rejected") {
    location.reload();
  }
}

Egy idcomponents-reconnect-max-retries rendelkező elem a csatlakozási újrakísérletek maximális számát jeleníti meg.

<span id="components-reconnect-max-retries"></span>

A idcomponents-reconnect-current-attempt rendelkező elem megjeleníti az aktuális újracsatlakozási kísérletet:

<span id="components-reconnect-current-attempt"></span>

A idcomponents-seconds-to-next-attempt elem megjeleníti a következő újracsatlakozási kísérletig hátralévő másodpercek számát.

<span id="components-seconds-to-next-attempt"></span>

A Blazor Web App projektsablon tartalmaz egy ReconnectModal olyan összetevőt (Components/Layout/ReconnectModal.razor) a csoportosított stíluslapokkal és a JavaScript-fájlokkal (ReconnectModal.razor.css, ReconnectModal.razor.js), amelyek igény szerint testre szabhatók. Ezek a fájlok a ASP.NET Core referenciaforrásában vagy a Blazor Web App projektsablonból létrehozott alkalmazás vizsgálatával vizsgálhatók meg. Az összetevő hozzáadódik a projekthez, amikor a projekt létrejön a Visual Studio-ban interaktív renderelési móddal, beállítvakiszolgálóként vagy automatikusra, vagy létrejön a .NET CLI segítségével az opcióval --interactivity server (alapértelmezett) vagy --interactivity auto.

Jegyzet

A .NET referenciaforrásra mutató dokumentációs hivatkozások általában betöltik az adattár alapértelmezett ágát, amely a .NET következő kiadásának aktuális fejlesztését jelöli. Egy adott kiadás címkéjének kiválasztásához használja a Ágak vagy címkék legördülő listát. További információ: A ASP.NET Core-forráskód (dotnet/AspNetCore.Docs #26205) verziócímkéjének kiválasztása.

Kiszolgálóoldali renderelés

Alapértelmezés szerint az összetevők előre vannak rendezve a kiszolgálón, mielőtt létrejön a kiszolgálóhoz való ügyfélkapcsolat. További információ: ASP.NET Core Blazor előre beállított állapotmegőrzés.

Kiszolgálóoldali kapcsolatcsoport tevékenységének figyelése

Bejövő áramköri aktivitás figyelése a CreateInboundActivityHandler módszerrel a CircuitHandler-en. A bejövő áramkör-tevékenység minden olyan tevékenység, amelyet a böngésző küld a kiszolgálónak, például UI események vagy JavaScript és .NET közötti interop hívások.

Egy kapcsolatcsoporttevékenység-kezelővel például észlelheti, hogy az ügyfél tétlen-e, és naplózza a kapcsolatcsoport azonosítóját (Circuit.Id):

using Microsoft.AspNetCore.Components.Server.Circuits;
using Microsoft.Extensions.Options;
using Timer = System.Timers.Timer;

public sealed class IdleCircuitHandler : CircuitHandler, IDisposable
{
    private Circuit? currentCircuit;
    private readonly ILogger logger;
    private readonly Timer timer;

    public IdleCircuitHandler(ILogger<IdleCircuitHandler> logger, 
        IOptions<IdleCircuitOptions> options)
    {
        timer = new Timer
        {
            Interval = options.Value.IdleTimeout.TotalMilliseconds,
            AutoReset = false
        };

        timer.Elapsed += CircuitIdle;
        this.logger = logger;
    }

    private void CircuitIdle(object? sender, System.Timers.ElapsedEventArgs e)
    {
        logger.LogInformation("{CircuitId} is idle", currentCircuit?.Id);
    }

    public override Task OnCircuitOpenedAsync(Circuit circuit, 
        CancellationToken cancellationToken)
    {
        currentCircuit = circuit;

        return Task.CompletedTask;
    }

    public override Func<CircuitInboundActivityContext, Task> CreateInboundActivityHandler(
        Func<CircuitInboundActivityContext, Task> next)
    {
        return context =>
        {
            timer.Stop();
            timer.Start();

            return next(context);
        };
    }

    public void Dispose() => timer.Dispose();
}

public class IdleCircuitOptions
{
    public TimeSpan IdleTimeout { get; set; } = TimeSpan.FromMinutes(5);
}

public static class IdleCircuitHandlerServiceCollectionExtensions
{
    public static IServiceCollection AddIdleCircuitHandler(
        this IServiceCollection services, 
        Action<IdleCircuitOptions> configureOptions)
    {
        services.Configure(configureOptions);
        services.AddIdleCircuitHandler();

        return services;
    }

    public static IServiceCollection AddIdleCircuitHandler(
        this IServiceCollection services)
    {
        services.AddScoped<CircuitHandler, IdleCircuitHandler>();

        return services;
    }
}

Regisztrálja a szolgáltatást a Program fájlban. Az alábbi példa az alapértelmezett üresjárati időtúllépést öt percről öt másodpercre állítja annak érdekében, hogy tesztelje az előző IdleCircuitHandler implementációt.

builder.Services.AddIdleCircuitHandler(options => 
    options.IdleTimeout = TimeSpan.FromSeconds(5));

Az áramkör tevékenységkezelők lehetővé teszik a hatókörrel rendelkező Blazor szolgáltatások elérését más, nemBlazor függőséginjektálási (DI) hatókörökből is. További információkért és példákért lásd:

• ASP.NET Core Blazor függőség injektálása
• ASP.NET Core kiszolgálóoldali és Blazor Web App további biztonsági forgatókönyvek

Blazor indítás

Konfigurálja BlazorSignalR áramkör manuális indítását egy App.razorBlazor Web App fájljában:

• Adjon hozzá egy autostart="false" attribútumot a <script> szkript blazor.*.js címkéjére.
• Helyezzen el egy szkriptet, amely a Blazor.start() szkript betöltése után és a záró Blazor címkén belül hívja meg a </body>.

Ha autostart le van tiltva, az alkalmazás minden olyan eleme, amely nem függ a kapcsolatcsoporttól, normálisan működik. Az ügyféloldali útválasztás például működőképes. Az áramkörtől függő bármely szempont azonban nem működik, amíg a Blazor.start() nincs meghívva. Az alkalmazás viselkedése kiszámíthatatlan létrehozott áramkör nélkül. Például a komponensmetódusok nem hajthatók végre, amíg az áramkör megszakad.

További információkért, beleértve, hogy hogyan inicializálható a Blazor, amikor a dokumentum készen áll, és hogyan történhet a láncolás a JS Promise-hez, lásd a ASP.NET Core Blazor indításicímű témakört.

SignalR időtúllépések és Keep-Alive konfigurálása az ügyfélen

Konfigurálja a következő értékeket az ügyfél számára.

• withServerTimeout: Milliszekundumban konfigurálja a kiszolgáló időtúllépését. Ha ez az időtúllépés a kiszolgálótól érkező üzenetek fogadása nélkül telik el, a kapcsolat megszakad egy hibával. Az alapértelmezett időtúllépési érték 30 másodperc. A kiszolgáló időtúllépésének legalább a Keep-Alive intervallumhoz (withKeepAliveInterval) rendelt érték kétszeresének kell lennie.
• withKeepAliveInterval: Ezredmásodpercben konfigurálja a Keep-Alive időközt (alapértelmezett időköz, amelyen a kiszolgáló pingelhető). Ez a beállítás lehetővé teszi, hogy a kiszolgáló észlelje a kapcsolat megszakadását, például amikor egy ügyfél leválasztja a számítógépét a hálózatról. A pingelés legfeljebb olyan gyakran történik, mint a kiszolgáló pingelése. Ha a kiszolgáló öt másodpercenként pingel, akkor 5000 (5 másodperc) alatti érték hozzárendelésével is öt másodpercenként fog pingelni. Az alapértelmezett érték 15 másodperc. A Keep-Alive intervallumnak kisebbnek vagy egyenlőnek kell lennie a kiszolgáló időtúllépéséhez (withServerTimeout) hozzárendelt érték felével.

A App.razor fájl (Blazor Web App) alábbi példája az alapértelmezett értékek hozzárendelését mutatja be.

Blazor Web App:

<script src="{BLAZOR SCRIPT}" autostart="false"></script>
<script>
  Blazor.start({
    circuit: {
      configureSignalR: function (builder) {
        builder.withServerTimeout(30000).withKeepAliveInterval(15000);
      }
    }
  });
</script>

Az alábbi példa a Pages/_Host.cshtml fájlra (Blazor Server, minden verzió esetében, kivéve ASP.NET Core a .NET 6-ban) vagy a Pages/_Layout.cshtml fájlra (Blazor Server, ASP.NET Core a .NET 6-ban).

Blazor Server:

<script src="{BLAZOR SCRIPT}" autostart="false"></script>
<script>
  Blazor.start({
    configureSignalR: function (builder) {
      builder.withServerTimeout(30000).withKeepAliveInterval(15000);
    }
  });
</script>

Az előző példában a {BLAZOR SCRIPT} helyőrző a Blazor szkript elérési útja és fájlneve. A szkript helyéről és a használni kívánt elérési útról a ASP.NET Core Blazor projektszerkezetcímű témakörben olvashat.

Ha központi kapcsolatot hoz létre egy összetevőben, állítsa be a következőket: ServerTimeout (alapértelmezett: 30 másodperc) és KeepAliveInterval (alapértelmezett: 15 másodperc) a HubConnectionBuilder-n. Állítsa be HandshakeTimeout-t (alapértelmezett: 15 másodperc) beépített HubConnection-en. Az alábbi példa az alapértelmezett értékek hozzárendelését mutatja be:

protected override async Task OnInitializedAsync()
{
    hubConnection = new HubConnectionBuilder()
        .WithUrl(Navigation.ToAbsoluteUri("/chathub"))
        .WithServerTimeout(TimeSpan.FromSeconds(30))
        .WithKeepAliveInterval(TimeSpan.FromSeconds(15))
        .Build();

    hubConnection.HandshakeTimeout = TimeSpan.FromSeconds(15);

    hubConnection.On<string, string>("ReceiveMessage", (user, message) => ...

    await hubConnection.StartAsync();
}

A kiszolgáló időtúllépésének (ServerTimeout) vagy Keep-Alive időközének (KeepAliveInterval) módosításakor:

• A kiszolgáló időtúllépésének legalább a Keep-Alive intervallumhoz rendelt érték kétszeresének kell lennie.
• A Keep-Alive intervallumnak kisebbnek vagy egyenlőnek kell lennie a kiszolgáló időtúllépéséhez hozzárendelt érték felével.

További információt a globális üzembe helyezési és csatlakozási hibák alábbi cikkek szakaszaiban talál:

• Blazor
• Hosztolás/telepítés ASP.NET Core Blazor WebAssembly

A kiszolgálóoldali újracsatlakozás újrapróbálkozási számának és időközének módosítása

Az újrakapcsolódási újrapróbálkozások számának és időközének módosításához állítsa be az újrapróbálkozások számát (maxRetries) és az egyes újrapróbálkozásokhoz engedélyezett időtartamot (retryIntervalMilliseconds).

Blazor Web App:

<script src="{BLAZOR SCRIPT}" autostart="false"></script>
<script>
  Blazor.start({
    circuit: {
      reconnectionOptions: {
        maxRetries: 3,
        retryIntervalMilliseconds: 2000
      }
    }
  });
</script>

Blazor Server:

<script src="{BLAZOR SCRIPT}" autostart="false"></script>
<script>
  Blazor.start({
    reconnectionOptions: {
      maxRetries: 3,
      retryIntervalMilliseconds: 2000
    }
  });
</script>

Az előző példában a {BLAZOR SCRIPT} helyőrző a Blazor szkript elérési útja és fájlneve. A szkript helyéről és a használni kívánt elérési útról a ASP.NET Core Blazor projektszerkezetcímű témakörben olvashat.

Amikor a felhasználó egy leválasztott kapcsolatcsoporttal rendelkező alkalmazásra lép vissza, a rendszer azonnal megkísérli az újracsatlakozást ahelyett, hogy a következő újracsatlakozási időköz időtartamára várna. Ez a viselkedés arra törekszik, hogy a lehető leggyorsabban folytassa a kapcsolatot a felhasználó számára.

Az alapértelmezett újracsatlakozási időzítés egy kiszámított visszavonulási stratégiát használ. Az első több újracsatlakozási kísérlet gyors egymásutánban történik, mielőtt kiszámított késések lépnek fel a kísérletek között. Az újrapróbálkozási időköz számításának alapértelmezett logikája egy olyan implementációs részlet, amelyet értesítés nélkül módosítani kell, de megtalálhatja az alapértelmezett logikát, amelyet a Blazor-keretrendszer használ a computeDefaultRetryInterval függvényben (referenciaforrás).

Jegyzet

A .NET referenciaforrásra mutató dokumentációs hivatkozások általában betöltik az adattár alapértelmezett ágát, amely a .NET következő kiadásának aktuális fejlesztését jelöli. Egy adott kiadás címkéjének kiválasztásához használja a Ágak vagy címkék legördülő listát. További információ: A ASP.NET Core-forráskód (dotnet/AspNetCore.Docs #26205) verziócímkéjének kiválasztása.

Az újrapróbálkozási időköz viselkedésének testreszabásához adjon meg egy függvényt az újrapróbálkozási időköz kiszámításához. A következő exponenciális visszalépési példában a korábbi újracsatlakozási kísérletek száma megszorozva 1000 ms-tal az újrapróbálkozási időköz kiszámításához. Ha a korábbi újracsatlakozási kísérletek száma (previousAttempts) nagyobb, mint a maximális újrapróbálkozási korlát (maxRetries), null van hozzárendelve az újrapróbálkozási időközhöz (retryIntervalMilliseconds) a további újracsatlakozási kísérletek leállításához:

Blazor.start({
  circuit: {
    reconnectionOptions: {
      retryIntervalMilliseconds: (previousAttempts, maxRetries) => 
        previousAttempts >= maxRetries ? null : previousAttempts * 1000
    },
  },
});

Másik lehetőségként megadhatja az újrapróbálkozási időközök pontos sorrendjét. Az utolsó megadott újrapróbálkozási időköz után az újrapróbálkozások leállnak, mert a retryIntervalMilliseconds függvény undefinedad vissza:

Blazor.start({
  circuit: {
    reconnectionOptions: {
      retryIntervalMilliseconds: 
        Array.prototype.at.bind([0, 1000, 2000, 5000, 10000, 15000, 30000]),
    },
  },
});

További információt a Blazor indításról az ASP.NET Core Blazor indításicímű témakörben találhat.

Annak szabályozása, hogy mikor jelenik meg az újracsatlakozási felhasználói felület

Az újracsatlakozási felhasználói felület megjelenésének szabályozása az alábbi helyzetekben lehet hasznos:

• Az üzembe helyezett alkalmazás gyakran újracsatlakozási felhasználói felületet jelenít meg a belső hálózat vagy az interneten tapasztalható késések miatt bekövetkező pingelési időtúllépések miatt, és szeretné növelni a késleltetési időt.
• Az alkalmazásnak hamarabb kellene jeleznie a felhasználóknak, hogy a kapcsolat megszakadt, és szeretnék lerövidíteni a késleltetést.

Az újracsatlakozási felhasználói felület megjelenésének időzítését az ügyfél Keep-Alive időközének és időtúllépéseinek módosítása befolyásolja. Az újracsatlakozási felhasználói felület akkor jelenik meg, amikor az ügyfélnél időtúllépés történik a kiszolgáló miatt (withServerTimeout, Ügyfélkonfiguráció szakasz). A withServerTimeout értékének módosításához azonban módosítani kell az alábbi útmutatóban leírt egyéb Keep-Alive, timeout és handshake beállításokat.

Általános javaslatok az alábbi útmutatáshoz:

• A Keep-Alive intervallumnak egyeznie kell az ügyfél- és kiszolgálókonfigurációk között.
• Az időtúllépéseknek legalább kétszeresének kell lenniük a Keep-Alive intervallumhoz rendelt értéknek.

Kiszolgálókonfiguráció

Állítsa be a következőket:

• ClientTimeoutInterval (alapértelmezett: 30 másodperc): Az időablakban az ügyfeleknek üzenetet kell küldeniük, mielőtt a kiszolgáló bezárja a kapcsolatot.
• HandshakeTimeout (alapértelmezett: 15 másodperc): A kiszolgáló által az ügyfelek bejövő kézfogási kéréseinek időtúllépésére alkalmazott intervallum.
• KeepAliveInterval (alapértelmezett: 15 másodperc): A kiszolgáló által az életben tartási pingek csatlakoztatott ügyfeleknek való küldéséhez használt időköz. Vegye figyelembe, hogy az ügyfélen Keep-Alive intervallumbeállítás is szerepel, amelynek meg kell egyeznie a kiszolgáló értékével.

A ClientTimeoutInterval és a HandshakeTimeout növelhető, és a KeepAliveInterval változatlanok maradhatnak. Fontos szempont, hogy ha módosítja az értékeket, győződjön meg arról, hogy az időtúllépések legalább kétszer akkorák, mint a Keep-Alive intervallum, és hogy a Keep-Alive intervallum megegyezik a kiszolgáló és az ügyfél között. További információért lásd az Ügyfél szakaszban az időtúllépések és a Keep-Alive konfigurálásának módjátSignalR.

Az alábbi példában:

• A ClientTimeoutInterval 60 másodpercre nő (alapértelmezett érték: 30 másodperc).
• A HandshakeTimeout 30 másodpercre nő (alapértelmezett érték: 15 másodperc).
• A KeepAliveInterval nincs beállítva a fejlesztői kódban, és az alapértelmezett 15 másodperces értéket használja. A Keep-Alive intervallum értékének csökkentése növeli a kommunikációs pingek gyakoriságát, ami növeli az alkalmazás, a kiszolgáló és a hálózat terhelését. Ügyelni kell arra, hogy a Keep-Alive intervallum csökkentésekor ne vezessen be gyenge teljesítményt.

Blazor Web App (.NET 8 vagy újabb) a kiszolgálóprojekt Program fájljában:

builder.Services.AddRazorComponents().AddInteractiveServerComponents()
    .AddHubOptions(options =>
{
    options.ClientTimeoutInterval = TimeSpan.FromSeconds(60);
    options.HandshakeTimeout = TimeSpan.FromSeconds(30);
});

Blazor Server a Program fájlban:

builder.Services.AddServerSideBlazor()
    .AddHubOptions(options =>
    {
        options.ClientTimeoutInterval = TimeSpan.FromSeconds(60);
        options.HandshakeTimeout = TimeSpan.FromSeconds(30);
    });

További információt a kiszolgálóoldali kapcsolatcsoport-kezelő beállításai szakaszban talál.

Ügyfélkonfiguráció

Állítsa be a következőket:

• withServerTimeout (alapértelmezett: 30 másodperc): A körvonali központkapcsolat kiszolgáló időkorlátját konfigurálja, amely ezredmásodpercben van megadva.
• withKeepAliveInterval (alapértelmezett: 15 másodperc): Ezredmásodpercben megadott időköz, amely után a kapcsolat Keep-Alive üzeneteket küld.

A kiszolgáló időkorlátja növelhető, és a Keep-Alive intervallum változatlan maradhat. A fontos szempont, hogy ha módosítja az értékeket, győződjön meg arról, hogy a kiszolgáló időtúllépése legalább a Keep-Alive intervallum értékének kétszerese, és hogy a Keep-Alive intervallumértékek megegyeznek a kiszolgáló és az ügyfél között. További információért lásd az Ügyfél szakaszban az időtúllépések és a Keep-Alive konfigurálásának módjátSignalR.

Az alábbi indítási konfiguráció példában (a Blazor szkript helye) a szerver időtúllépéséhez egyéni, 60 másodperces értéket használunk. A Keep-Alive intervallum (withKeepAliveInterval) nincs beállítva, és az alapértelmezett 15 másodperces értéket használja.

Blazor Web App:

<script src="{BLAZOR SCRIPT}" autostart="false"></script>
<script>
  Blazor.start({
    circuit: {
      configureSignalR: function (builder) {
        builder.withServerTimeout(60000);
      }
    }
  });
</script>

Blazor Server:

<script src="{BLAZOR SCRIPT}" autostart="false"></script>
<script>
  Blazor.start({
    configureSignalR: function (builder) {
      builder.withServerTimeout(60000);
    }
  });
</script>

Ha egy hubkapcsolatot hoz létre egy összetevőben, állítsa be a kiszolgáló időtúllépését (WithServerTimeout, alapértelmezett: 30 másodperc) a HubConnectionBuilder függvényében. Állítsa be HandshakeTimeout-t (alapértelmezett: 15 másodperc) beépített HubConnection-en. Győződjön meg arról, hogy az időtúllépések hossza legalább kétszerese a Keep-Alive intervallumnak (WithKeepAliveInterval/KeepAliveInterval), és hogy a Keep-Alive érték megegyezik a kiszolgáló és az ügyfél között.

Az alábbi példa a IndexSignalR összetevőn, a Blazor oktatóanyag-ben alapul. A kiszolgáló időtúllépése 60 másodpercre nő, a kézfogás időtúllépése pedig 30 másodpercre nő. A Keep-Alive intervallum nincs beállítva, és az alapértelmezett 15 másodperces értéket használja.

protected override async Task OnInitializedAsync()
{
    hubConnection = new HubConnectionBuilder()
        .WithUrl(Navigation.ToAbsoluteUri("/chathub"))
        .WithServerTimeout(TimeSpan.FromSeconds(60))
        .Build();

    hubConnection.HandshakeTimeout = TimeSpan.FromSeconds(30);

    hubConnection.On<string, string>("ReceiveMessage", (user, message) => ...

    await hubConnection.StartAsync();
}

A kiszolgálóoldali újracsatlakozási kezelő módosítása

Az újrakapcsolódási kezelő áramkör-kapcsolati eseményei módosíthatók egyéni viselkedésekhez, például:

• A felhasználó értesítése a kapcsolat megszakadásáról.
• A naplózás végrehajtása az ügyfél részéről, amikor egy áramkör csatlakozik.

A kapcsolati események módosításához regisztráljon visszahívásokat a következő kapcsolatváltozásokhoz:

• A megszakadt kapcsolatok onConnectionDown-t használnak.
• A létrehozott/újra létrehozott kapcsolatok onConnectionUphasználnak.

onConnectionDown és onConnectionUp is meg kell adni.

Blazor Web App:

<script src="{BLAZOR SCRIPT}" autostart="false"></script>
<script>
  Blazor.start({
    circuit: {
      reconnectionHandler: {
        onConnectionDown: (options, error) => console.error(error),
        onConnectionUp: () => console.log("Up, up, and away!")
      }
    }
  });
</script>

Blazor Server:

<script src="{BLAZOR SCRIPT}" autostart="false"></script>
<script>
  Blazor.start({
    reconnectionHandler: {
      onConnectionDown: (options, error) => console.error(error),
      onConnectionUp: () => console.log("Up, up, and away!")
    }
  });
</script>

Az előző példában a {BLAZOR SCRIPT} helyőrző a Blazor szkript elérési útja és fájlneve. A szkript helyéről és a használni kívánt elérési útról a ASP.NET Core Blazor projektszerkezetcímű témakörben olvashat.

Az újracsatlakozás és az újratöltés viselkedésének programozott vezérlése

Blazor automatikusan megkísérli az újracsatlakozást, és frissíti a böngészőt, ha az újracsatlakozás meghiúsul. További információ: A kiszolgálóoldali újracsatlakozás újrapróbálkozási számának és időközének beállítása szakasz. A fejlesztői kód azonban implementálhat egy egyéni újracsatlakozási kezelőt, hogy teljes mértékben átvegye az újracsatlakozás viselkedését.

App.razor:

<div id="reconnect-modal" style="display: none;"></div>
<script src="{BLAZOR SCRIPT}" autostart="false"></script>
<script src="boot.js"></script>

Az előző példában a {BLAZOR SCRIPT} helyőrző a Blazor szkript elérési útja és fájlneve. A szkript helyéről és a használni kívánt elérési útról a ASP.NET Core Blazor projektszerkezetcímű témakörben olvashat.

Hozza létre a következő wwwroot/boot.js fájlt.

Blazor Web App:

(() => {
  const maximumRetryCount = 3;
  const retryIntervalMilliseconds = 5000;
  const reconnectModal = document.getElementById('reconnect-modal');

  const startReconnectionProcess = () => {
    reconnectModal.style.display = 'block';

    let isCanceled = false;

    (async () => {
      for (let i = 0; i < maximumRetryCount; i++) {
        reconnectModal.innerText = `Attempting to reconnect: ${i + 1} of ${maximumRetryCount}`;

        await new Promise(resolve => setTimeout(resolve, retryIntervalMilliseconds));

        if (isCanceled) {
          return;
        }

        try {
          const result = await Blazor.reconnect();
          if (!result) {
            // The server was reached, but the connection was rejected; reload the page.
            location.reload();
            return;
          }

          // Successfully reconnected to the server.
          return;
        } catch {
          // Didn't reach the server; try again.
        }
      }

      // Retried too many times; reload the page.
      location.reload();
    })();

    return {
      cancel: () => {
        isCanceled = true;
        reconnectModal.style.display = 'none';
      },
    };
  };

  let currentReconnectionProcess = null;

  Blazor.start({
    circuit: {
      reconnectionHandler: {
        onConnectionDown: () => currentReconnectionProcess ??= startReconnectionProcess(),
        onConnectionUp: () => {
          currentReconnectionProcess?.cancel();
          currentReconnectionProcess = null;
        }
      }
    }
  });
})();

Blazor Server:

(() => {
  const maximumRetryCount = 3;
  const retryIntervalMilliseconds = 5000;
  const reconnectModal = document.getElementById('reconnect-modal');

  const startReconnectionProcess = () => {
    reconnectModal.style.display = 'block';

    let isCanceled = false;

    (async () => {
      for (let i = 0; i < maximumRetryCount; i++) {
        reconnectModal.innerText = `Attempting to reconnect: ${i + 1} of ${maximumRetryCount}`;

        await new Promise(resolve => setTimeout(resolve, retryIntervalMilliseconds));

        if (isCanceled) {
          return;
        }

        try {
          const result = await Blazor.reconnect();
          if (!result) {
            // The server was reached, but the connection was rejected; reload the page.
            location.reload();
            return;
          }

          // Successfully reconnected to the server.
          return;
        } catch {
          // Didn't reach the server; try again.
        }
      }

      // Retried too many times; reload the page.
      location.reload();
    })();

    return {
      cancel: () => {
        isCanceled = true;
        reconnectModal.style.display = 'none';
      },
    };
  };

  let currentReconnectionProcess = null;

  Blazor.start({
    reconnectionHandler: {
      onConnectionDown: () => currentReconnectionProcess ??= startReconnectionProcess(),
      onConnectionUp: () => {
        currentReconnectionProcess?.cancel();
        currentReconnectionProcess = null;
      }
    }
  });
})();

További információt a Blazor indításról az ASP.NET Core Blazor indításicímű témakörben találhat.

A BlazorSignalR áramkörének leválasztása az ügyféltől

Blazor SignalR áramkör megszakításra kerül a unload lap eseményének aktiválásakor. Az áramkör leválasztásához a kliens egyéb forgatókönyveihez hívja meg a Blazor.disconnect-et a megfelelő eseménykezelőben. Az alábbi példában az áramkör megszakad, amikor a lap rejtett (pagehide esemény):

window.addEventListener('pagehide', () => {
  Blazor.disconnect();
});

További információt a Blazor indításról az ASP.NET Core Blazor indításicímű témakörben találhat.

Kiszolgálóoldali áramkörkezelő

Definiálhat egy kapcsolatcsoport-kezelőt, amely lehetővé teszi a kód futtatását a felhasználói kapcsolatcsoport állapotának változásain. Az áramkör kezelő a CircuitHandler-ból származtatva valósul meg, és az osztályt regisztrálja az alkalmazás szolgáltatástárolójában. Az alábbi példa egy áramköri kezelőre, amely követi a nyitott SignalR kapcsolatokat.

TrackingCircuitHandler.cs:

using Microsoft.AspNetCore.Components.Server.Circuits;

public class TrackingCircuitHandler : CircuitHandler
{
    private HashSet<Circuit> circuits = new();

    public override Task OnConnectionUpAsync(Circuit circuit, 
        CancellationToken cancellationToken)
    {
        circuits.Add(circuit);

        return Task.CompletedTask;
    }

    public override Task OnConnectionDownAsync(Circuit circuit, 
        CancellationToken cancellationToken)
    {
        circuits.Remove(circuit);

        return Task.CompletedTask;
    }

    public int ConnectedCircuits => circuits.Count;
}

A kapcsolatcsoport-kezelők a DI használatával vannak regisztrálva. A hatókörrel rendelkező példányok minden egyes áramkör példányához létrejönnek. Az előző példában szereplő TrackingCircuitHandler használva létrejön egy egyszeri szolgáltatás, mert az összes kapcsolatcsoport állapotát nyomon kell követni.

A Program fájlban:

builder.Services.AddSingleton<CircuitHandler, TrackingCircuitHandler>();

Ha egy egyéni kapcsolatcsoport-kezelő metódusai kezeletlen kivételt eredményeznek, a kivétel végzetes a kapcsolatcsoport számára. A kezelő kódjában vagy hívott metódusokban előforduló kivételek kezeléséhez vonja be a kódot egy vagy több try-catch utasítással, biztosítva a hibakezelést és a naplózást.

Ha egy kapcsolatcsoport megszakad, mert egy felhasználó megszakította a kapcsolatot, és a keretrendszer megtisztítja a kapcsolatcsoport állapotát, a keretrendszer a kapcsolatcsoport DI-hatókörét megsemmisíti. A hatókör megsemmisítése minden olyan áramkör-hatókörű DI szolgáltatást elpusztít, amelyik implementálja a System.IDisposable-t. Ha bármely DI szolgáltatás kezeletlen kivételt okoz az ártalmatlanítás során, a keretrendszer naplózza a kivételt. További információkért lásd: ASP.NET Core Blazor függőségek befecskendezése.

Kiszolgálóoldali kapcsolatcsoport-kezelő az egyéni szolgáltatások felhasználóinak rögzítéséhez

Egy CircuitHandler segítségével kiválaszthat egy felhasználót a AuthenticationStateProvider-ből, és hozzárendelheti a felhasználót egy szolgáltatáshoz. További információ és példakód: ASP.NET Core kiszolgálóoldali és Blazor Web App további biztonsági forgatókönyvek.

Kapcsolatcsoportok bezárása, ha nincsenek fennmaradó interaktív kiszolgáló-összetevők

Az interaktív kiszolgálóösszetevők valós idejű kapcsolattal kezelik a webes felhasználói felület eseményeit egy kapcsolatcsoportnak nevezett böngészővel. Egy áramkör és a hozzá tartozó állapot akkor jön létre, amikor egy gyökér interaktív szerver komponens renderelődik. A kapcsolatcsoport akkor lesz bezárva, ha a lapon nincsenek fennmaradó interaktív kiszolgálói összetevők, ami felszabadítja a kiszolgáló erőforrásait.

Indítsa el a SignalR-kapcsolatcsoportot egy másik URL-címen

Az alkalmazás automatikus indításának megakadályozása autostart="false" hozzáadásával a Blazor<script> címkéhez (a Blazor indítási szkripthelye). Az áramkör URL-címének manuális létrehozása a Blazor.starthasználatával. Az alábbi példák a /signalrelérési utat használják.

Blazor Web App:

- <script src="_framework/blazor.web.js"></script>
+ <script src="_framework/blazor.web.js" autostart="false"></script>
+ <script>
+   Blazor.start({
+     circuit: {
+       configureSignalR: builder => builder.withUrl("/signalr")
+     },
+   });
+ </script>

Blazor Server:

- <script src="_framework/blazor.server.js"></script>
+ <script src="_framework/blazor.server.js" autostart="false"></script>
+ <script>
+   Blazor.start({
+     configureSignalR: builder => builder.withUrl("/signalr")
+   });
+ </script>

Adja hozzá a következő MapBlazorHub hívást a kiszolgálóalkalmazás Program fájljához a köztes feldolgozási folyamat csomópont elérési útjával.

Blazor Web App:

app.MapBlazorHub("/signalr");

Blazor Server:

Hagyja meg a meglévő MapBlazorHub hívást a fájlban, és adjon hozzá új MapBlazorHub hívást a következő elérési úttal:

app.MapBlazorHub();
+ app.MapBlazorHub("/signalr");

Megszemélyesítés Windows-hitelesítéshez

Hitelesített csatlakozások (HubConnection) UseDefaultCredentials segítségével jönnek létre, hogy jelezzék a HTTP-kérések alapértelmezett hitelesítő adatainak használatát. További információ: Hitelesítés és engedélyezés ASP.NET Core SignalR.

Ha az alkalmazás az IIS Expressben bejelentkezett felhasználóként fut a Windows-hitelesítés alatt, amely valószínűleg a felhasználó személyes vagy munkahelyi fiókja, az alapértelmezett hitelesítő adatok a bejelentkezett felhasználóé.

Amikor az alkalmazást közzéteszik az IIS-ben, az alkalmazás a alkalmazáskészlet Identityalatt fut. A HubConnection az alkalmazást üzemeltető IIS-fiókként csatlakozik, nem pedig az oldalhoz hozzáférő felhasználóként.

Implementálja a megszemélyesítést a HubConnection a böngészési felhasználó identitásának használatához.

Az alábbi példában:

• A hitelesítési állapotszolgáltató felhasználója egy WindowsIdentitytípusra konvertálódik.
• Az identitás hozzáférési jogkivonata átadásra kerül a WindowsIdentity.RunImpersonatedAsync-nak a HubConnectionkompiláló és indító kódjával.

protected override async Task OnInitializedAsync()
{
    var authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();

    if (authState?.User.Identity is not null)
    {
        var user = authState.User.Identity as WindowsIdentity;

        if (user is not null)
        {
            await WindowsIdentity.RunImpersonatedAsync(user.AccessToken, 
                async () =>
                {
                    hubConnection = new HubConnectionBuilder()
                        .WithUrl(NavManager.ToAbsoluteUri("/hub"), config =>
                        {
                            config.UseDefaultCredentials = true;
                        })
                        .WithAutomaticReconnect()
                        .Build();

                        hubConnection.On<string>("name", userName =>
                        {
                            name = userName;
                            InvokeAsync(StateHasChanged);
                        });

                        await hubConnection.StartAsync();
                });
        }
    }
}

Az előző kódban a NavManager egy NavigationManager, AuthenticationStateProvider pedig egy AuthenticationStateProvider szolgáltatáspéldány (aAuthenticationStateProvider dokumentáció).

További kiszolgálóoldali erőforrások

• kiszolgálóoldali kiszolgáló és üzembe helyezésre vonatkozó útmutató: SignalR konfiguráció
• ASP.NET Core SignalR áttekintése
• ASP.NET Core SignalR konfiguráció
• Kiszolgálóoldali biztonsági dokumentáció
  • ASP.NET Core Blazor hitelesítési és engedélyezési
  • ASP.NET Core Blazor hitelesítési és engedélyezési
  • Fenyegetés mérséklésére vonatkozó útmutató ASP.NET Core Blazor interaktív kiszolgálóoldali rendereléshez
  • ASP.NET Core kiszolgálóoldali és Blazor Web App további biztonsági forgatókönyvek
• IHttpContextAccessor/HttpContext ASP.NET Core Blazor-alkalmazásokban
• kiszolgálóoldali újracsatlakozási események és az összetevők életciklusának eseményei
• Mi az Az Azure SignalR Szolgáltatás?
• Teljesítmény útmutató az Azure SignalR Szolgáltatás
• ASP.NET Core SignalR-alkalmazás közzététele az Azure App Service-ben
• Blazor minták a GitHub adattárból (dotnet/blazor-samples) (hogyan lehet letölteni)