Blazor ASP.NET základní progresivní webová aplikace (PWA)

Blazor Progresivní webová aplikace (PWA) je jednostránkové aplikace (SPA), která používá moderní rozhraní API a možnosti prohlížeče, které se chovají jako desktopová aplikace.

Blazor WebAssembly je platforma webové aplikace založená na standardech, takže může používat libovolné rozhraní API prohlížeče, včetně rozhraní API PWA vyžadovaných pro následující funkce:

• Práce offline a načítání okamžitě nezávisle na rychlosti sítě.
• Spuštění ve vlastním okně aplikace, nejen v okně prohlížeče.
• Spouští se z nabídky Start operačního systému hostitele, doku nebo home obrazovky.
• Příjem nabízených oznámení z back-endového serveru, i když uživatel aplikaci nepoužívá.
• Automatická aktualizace na pozadí

Slovo progresivní se používá k popisu těchto aplikací, protože:

• Uživatel může nejprve zjistit a používat aplikaci ve webovém prohlížeči, jako je jakákoli jiná spa.
• Později uživatel pokračuje v instalaci do operačního systému a povolení nabízených oznámení.

Vytvoření projektu ze šablony PWA

dotnet new blazorwasm -o MyBlazorPwa --pwa

Převod existující Blazor WebAssembly aplikace na PWA

Podle pokynů v této části převeďte existující Blazor WebAssembly aplikaci na PWA.

V souboru projektu aplikace:

• Přidejte následující ServiceWorkerAssetsManifest vlastnost do PropertyGroup:

    ...
    <ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>
  </PropertyGroup>
  

• Přidejte následující ServiceWorker položku do ItemGroup:

  <ItemGroup>
    <ServiceWorker Include="wwwroot\service-worker.js" 
      PublishedContent="wwwroot\service-worker.published.js" />
  </ItemGroup>
  

Pokud chcete získat statické prostředky, použijte jeden z následujících přístupů:

• Vytvořte samostatný nový projekt PWA pomocí dotnet new příkazu v příkazovém prostředí:

  dotnet new blazorwasm -o MyBlazorPwa --pwa
  

  V předchozím příkazu vytvoří -o|--output možnost novou složku pro aplikaci s názvem MyBlazorPwa.

  Pokud nepřevádíte aplikaci pro nejnovější verzi, předejte tuto -f|--framework možnost. Následující příklad vytvoří aplikaci pro ASP.NET Core verze 5.0:

  dotnet new blazorwasm -o MyBlazorPwa --pwa -f net5.0
  

• Přidejte následující <script> značku do uzavírací </body> značky hned za blazor.webassembly.js značku skriptu:

      ...
      <script>navigator.serviceWorker.register('service-worker.js');</script>
  </body>
  

Manifest instalace a aplikace

Při návštěvě aplikace vytvořené pomocí šablony PWA mají uživatelé možnost nainstalovat aplikaci do nabídky Start, docku nebo home obrazovky operačního systému. Způsob zobrazení této možnosti závisí na prohlížeči uživatele. Pokud používáte desktopové prohlížeče založené na Chromiu, jako je Edge nebo Chrome, zobrazí se na panelu URL tlačítko Přidat . Jakmile uživatel vybere tlačítko Přidat , zobrazí se potvrzovací dialogové okno:

V iOSu si návštěvníci můžou aplikaci PWA nainstalovat pomocí tlačítka Sdílet v Safari a možnosti Přidat na domovskou obrazovku. V Chromu pro Android by uživatelé měli vybrat tlačítko Nabídky v pravém horním rohu a pak přidat na Home obrazovku.

Po instalaci se aplikace zobrazí ve vlastním okně bez adresního řádku:

Pokud chcete přizpůsobit název okna, barevné schéma, ikonu nebo další podrobnosti, podívejte se na manifest.json soubor v adresáři projektu wwwroot . Schéma tohoto souboru je definováno webovými standardy. Další informace najdete ve webové dokumentaci MDN: Manifest webové aplikace.

Offline podpora

Aplikace vytvořené pomocí možnosti šablony PWA mají podporu pro spuštění offline. Uživatel musí nejprve navštívit aplikaci, když je online. Prohlížeč automaticky stáhne a ukládá všechny prostředky potřebné k provozu offline.

Pokud chcete zjistit, jak funguje podpora offline:

1. Umožňuje publikovat aplikaci. Další informace najdete v tématu Hostitel a nasazení ASP.NET Core Blazor.

2. Nasaďte aplikaci na server, který podporuje PROTOKOL HTTPS, a přejděte k aplikaci v prohlížeči na jeho zabezpečené adrese HTTPS.

3. Otevřete vývojářské nástroje prohlížeče a ověřte, že je pracovník služby zaregistrovaný pro hostitele na kartě Aplikace :

   

4. Znovu načtěte stránku a prozkoumejte kartu Síť . Služba Service Worker nebo mezipaměť paměti jsou uvedeny jako zdroje pro všechny prostředky stránky:

   

5. Pokud chcete ověřit, že prohlížeč není závislý na síťovém přístupu k načtení aplikace, proveďte následující:

   • Vypněte webový server a podívejte se, jak aplikace funguje normálně, včetně opětovného načtení stránky. Stejně tak aplikace dál funguje normálně, když je pomalé síťové připojení.
   • Řekněte prohlížeči, aby na kartě Síť simuloval offline režim:

   

Offline podpora pomocí pracovního procesu služby je webový standard, nikoli specifický pro Blazor. Další informace o pracovních procesech služeb najdete ve webové dokumentaci MDN: Rozhraní API pracovního procesu služby. Další informace o běžných vzorech použití pracovních procesů služeb najdete v tématu Google Web: Životní cyklus pracovního procesu služby.

BlazorŠablona PWA vytvoří dva soubory pracovních procesů služby:

• wwwroot/service-worker.js, který se používá při vývoji.
• wwwroot/service-worker.published.js, který se použije po publikování aplikace.

Pokud chcete sdílet logiku mezi těmito dvěma soubory pracovních procesů služby, zvažte následující přístup:

• Přidejte třetí javascriptový soubor, který bude obsahovat společnou logiku.
• Umožňuje self.importScripts načíst společnou logiku do obou souborů pracovních procesů služby.

Strategie načítání první mezipaměti

service-worker.published.js Integrovaný pracovní proces služby vyřeší požadavky pomocí strategie první mezipaměti. To znamená, že pracovní proces služby dává přednost vrácení obsahu uloženého v mezipaměti bez ohledu na to, jestli má uživatel přístup k síti nebo je na serveru dostupný novější obsah.

Strategie první mezipaměti je cenná, protože:

• Zajišťuje spolehlivost. Přístup k síti není logický stav. Uživatel není jednoduše online ani offline:

  • Zařízení uživatele může předpokládat, že je online, ale síť může být tak pomalá, jako by bylo nepraktické čekat.
  • Síť může vrátit neplatné výsledky pro určité adresy URL, jako je například v případě, že je aktuálně blokující nebo přesměrovává určité požadavky portál wi-fi.

  Proto rozhraní API prohlížeče navigator.onLine není spolehlivé a nemělo by na něm záviset.

• Zajišťuje správnost. Při vytváření mezipaměti offline prostředků pracovní proces služby používá hashování obsahu, aby zajistil, že najednou načte kompletní a self-konzistentní snímek prostředků. Tato mezipaměť se pak použije jako atomická jednotka. Není potřeba žádat síť o novější prostředky, protože jediné požadované verze jsou ty, které už jsou uložené v mezipaměti. Cokoli jiného riskuje nekonzistence a nekompatibilitu (například při pokusu o použití verzí sestavení .NET, která nebyla kompilována společně).

Pokud musíte prohlížeči zabránit v načtení service-worker-assets.js z mezipaměti HTTP, například k vyřešení dočasných selhání kontroly integrity při nasazování nové verze pracovního procesu služby, aktualizujte registraci wwwroot/index.html pracovního procesu služby nastavenou updateViaCache na hodnotu None:

<script>
  navigator.serviceWorker.register('/service-worker.js', {updateViaCache: 'none'});
</script>

Aktualizace na pozadí

Jako mentální model si můžete představit offline aplikaci PWA jako mobilní aplikaci, která se dá nainstalovat. Aplikace se spustí okamžitě bez ohledu na připojení k síti, ale nainstalovaná logika aplikace pochází ze snímku k určitému bodu v čase, který nemusí být nejnovější verzí.

Šablona Blazor PWA vytvoří aplikace, které se automaticky pokusí aktualizovat na pozadí, kdykoli uživatel navštíví a má funkční síťové připojení. Způsob, jakým to funguje, je následující:

• Během kompilace projekt vygeneruje manifest prostředků pracovního procesu služby, který má název service-worker-assets.js. Manifest obsahuje seznam všech statických prostředků, které aplikace vyžaduje, aby fungovala offline, jako jsou sestavení .NET, soubory JavaScriptu a šablony stylů CSS, včetně jejich hodnot hash obsahu. Seznam prostředků načte pracovní proces služby, aby věděl, které prostředky se mají ukládat do mezipaměti.
• Pokaždé, když uživatel navštíví aplikaci, prohlížeč znovu požádá service-worker.js a service-worker-assets.js na pozadí. Soubory se porovnávají bajty pro bajt s existujícím nainstalovaným pracovním procesem služby. Pokud server vrátí změněný obsah pro některý z těchto souborů, pracovní proces služby se pokusí nainstalovat novou verzi sebe sama.
• Při instalaci nové verze sama o sobě pracovní proces služby vytvoří novou, samostatnou mezipaměť pro offline prostředky a spustí naplnění mezipaměti prostředky uvedenými v service-worker-assets.js. Tato logika je implementována onInstall ve funkci uvnitř service-worker.published.js.
• Proces se úspěšně dokončí, když se všechny prostředky načtou bez chyb a všechny hodnoty hash obsahu se shodují. V případě úspěchu nový pracovní proces služby přejde do stavu čekání na aktivaci . Jakmile uživatel aplikaci zavře (žádné zbývající karty nebo okna aplikace), nový pracovní proces služby se aktivuje a použije se pro následné návštěvy aplikace. Starý pracovní proces služby a jeho mezipaměť se odstraní.
• Pokud se proces úspěšně nedokončí, nová instance pracovního procesu služby se zahodí. Proces aktualizace se pokusí znovu na příští návštěvě uživatele, když snad má klient lepší síťové připojení, které může žádosti dokončit.

Upravte tento proces úpravou logiky pracovního procesu služby. Žádné z předchozích chování není specifické, Blazor ale je pouze výchozím prostředím, které poskytuje možnost šablony PWA. Další informace najdete ve webové dokumentaci MDN: Rozhraní SERVICE Worker API.

Způsob řešení požadavků

Jak je popsáno v části strategie načtení mezipaměti, výchozí pracovní proces služby používá strategii první mezipaměti, což znamená, že se pokusí obsluhovat obsah uložený v mezipaměti, pokud je k dispozici. Pokud pro určitou adresu URL neexistuje žádný obsah uložený v mezipaměti, například při vyžádání dat z back-endového rozhraní API, pracovní proces služby se vrátí k běžnému síťovému požadavku. Síťový požadavek bude úspěšný, pokud je server dostupný. Tato logika se implementuje uvnitř onFetch funkce v rámci service-worker.published.js.

Pokud komponenty aplikace Razor spoléhají na vyžádání dat z back-endových rozhraní API a chcete poskytnout přívětivé uživatelské prostředí pro neúspěšné požadavky kvůli nedostupnosti sítě, implementujte logiku v rámci komponent aplikace. Můžete například použít try/catch žádosti HttpClient .

Podpora stránek vykreslených serverem

Zamyslete se nad tím, co se stane, když uživatel poprvé přejde na adresu URL, například /counter na jakýkoli jiný přímý odkaz v aplikaci. V těchto případech nechcete vracet obsah uložený v mezipaměti, /counterale místo toho potřebujete, aby prohlížeč načetl obsah uložený v mezipaměti, aby /index.html se spustila vaše Blazor WebAssembly aplikace. Tyto počáteční požadavky se označují jako navigační požadavky, na rozdíl od těchto požadavků:

• subresource požadavky na obrázky, šablony stylů nebo jiné soubory.
• fetch/XHR požadavky na data rozhraní API.

Výchozí pracovní proces služby obsahuje pro požadavky navigace zvláštní logiku. Pracovní proces služby vyřeší požadavky vrácením obsahu uloženého v mezipaměti bez /index.htmlohledu na požadovanou adresu URL. Tato logika je implementována onFetch ve funkci uvnitř service-worker.published.js.

Pokud má vaše aplikace určité adresy URL, které musí vracet kód HTML vykreslený serverem, a nikoli /index.html z mezipaměti, musíte upravit logiku pracovního procesu služby. Pokud všechny adresy URL obsahující /Identity/ je potřeba zpracovat jako běžné online požadavky pouze na server, upravte service-worker.published.js onFetch logiku. Vyhledejte následující kód:

const shouldServeIndexHtml = event.request.mode === 'navigate';

Změňte kód na následující:

const shouldServeIndexHtml = event.request.mode === 'navigate'
  && !event.request.url.includes('/Identity/');

Pokud to neuděláte, pak bez ohledu na síťové připojení zachytí pracovník služby požadavky na tyto adresy URL a vyřeší je pomocí /index.html.

Přidejte do kontroly další koncové body externích zprostředkovatelů ověřování. V následujícím příkladu /signin-google se do kontroly přidá ověřování Google:

const shouldServeIndexHtml = event.request.mode === 'navigate'
  && !event.request.url.includes('/Identity/')
  && !event.request.url.includes('/signin-google');

Pro Development prostředí není nutná žádná akce, kde se obsah vždy načte ze sítě.

Řízení ukládání prostředků do mezipaměti

Pokud váš projekt definuje ServiceWorkerAssetsManifest vlastnost MSBuild, Blazornástroj sestavení generuje manifest prostředků pracovního procesu služby se zadaným názvem. Výchozí šablona PWA vytvoří soubor projektu obsahující následující vlastnost:

<ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>

Soubor je umístěn ve výstupním wwwroot adresáři, takže prohlížeč může tento soubor načíst vyžádáním /service-worker-assets.js. Pokud chcete zobrazit obsah tohoto souboru, otevřete /bin/Debug/{TARGET FRAMEWORK}/wwwroot/service-worker-assets.js ho v textovém editoru. Soubor ale neupravujte, protože se v každém sestavení znovu vygeneruje.

Seznam manifestů:

• Všechny Blazorspravované prostředky, jako jsou sestavení .NET a soubory modulu runtime .NET WebAssembly potřebné k fungování offline.
• Všechny prostředky pro publikování do adresáře aplikace wwwroot , jako jsou obrázky, šablony stylů a soubory JavaScriptu, včetně statických webových prostředků poskytovaných externími projekty a balíčky NuGet.

Můžete řídit, které z těchto prostředků se načítají a ukládají do mezipaměti pracovním procesem služby úpravou logiky v onInstall service-worker.published.jssouboru . Pracovní proces služby načte a ukládá soubory do mezipaměti odpovídající typickým příponám názvů webových souborů, jako .htmljsou například , .css, .jsa .wasmtypy souborů specifické pro Blazor WebAssembly, například .pdb soubory (všechny verze) a .dll soubory (ASP.NET Core v .NET 7 nebo starší).

Pokud chcete zahrnout další prostředky, které nejsou přítomné v adresáři aplikace wwwroot , definujte další položky NÁSTROJE MSBuild ItemGroup , jak je znázorněno v následujícím příkladu:

<ItemGroup>
  <ServiceWorkerAssetsManifestItem Include="MyDirectory\AnotherFile.json"
    RelativePath="MyDirectory\AnotherFile.json" AssetUrl="files/AnotherFile.json" />
</ItemGroup>

Metadata AssetUrl určuje základní relativní adresu URL, kterou má prohlížeč použít při načítání prostředku do mezipaměti. To může být nezávislé na původním názvu zdrojového souboru na disku.

Nabízená oznámení

Stejně jako jakékoli jiné PWA může PWA Blazor WebAssembly přijímat nabízená oznámení z back-endového serveru. Server může odesílat nabízená oznámení kdykoli, i když uživatel aplikaci aktivně nepoužívá. Nabízená oznámení se dají například odeslat, když jiný uživatel provede příslušnou akci.

Mechanismus odesílání nabízených oznámení je zcela nezávislý na Blazor WebAssemblytom, protože je implementovaný back-endovým serverem, který může používat libovolnou technologii. Pokud chcete posílat nabízená oznámení ze serveru ASP.NET Core, zvažte použití techniky podobné přístupu, který jste provedli v workshopu Blazing Pizza.

Mechanismus pro příjem a zobrazení nabízeného oznámení na klientovi je také nezávislý na Blazor WebAssemblytom, protože je implementován v souboru JavaScript pracovního procesu služby. Příklad najdete v přístupu použitém v workshopu Blazing Pizza.

Upozornění pro offline PWA

Ne všechny aplikace by se měly pokoušet podporovat offline použití. Podpora offline zvyšuje značnou složitost, ale nemusí být vždy relevantní pro požadované případy použití.

Offline podpora je obvykle relevantní pouze:

• Pokud je primární úložiště dat v prohlížeči místní. Přístup je například relevantní v aplikaci s uživatelským rozhraním pro zařízení IoT , které ukládá data do localStorage nebo IndexedDB.
• Pokud aplikace provádí značné množství práce při načítání a ukládání dat back-endového rozhraní API do mezipaměti relevantních pro každého uživatele, aby mohl procházet data offline. Pokud aplikace musí podporovat úpravy, musí být sestaven systém pro sledování změn a synchronizaci dat s back-endem.
• Pokud je cílem zaručit, že se aplikace načte okamžitě bez ohledu na síťové podmínky. Implementujte vhodné uživatelské prostředí kolem požadavků rozhraní API back-endu, aby bylo možné zobrazit průběh požadavků a chovat se elegantně, když požadavky selžou kvůli nedostupnosti sítě.

Kromě toho musí offline podporující PWA řešit řadu dalších komplikací. Vývojáři by se měli pečlivě seznámit s upozorněními v následujících částech.

Offline podpora pouze při publikování

Během vývoje se obvykle každá změna projeví okamžitě v prohlížeči, aniž byste museli procházet procesem aktualizace na pozadí. BlazorŠablona PWA proto umožňuje offline podporu pouze při publikování.

Při vytváření aplikace podporující offline není dostatek k otestování aplikace v Development prostředí. Aplikaci musíte otestovat v publikovaném stavu, abyste pochopili, jak reaguje na různé síťové podmínky.

Aktualizace dokončení po navigaci uživatele mimo aplikaci

Aktualizace se nedokončí, dokud uživatel nepřejde z aplikace na všech kartách. Jak je vysvětleno v části Aktualizace na pozadí, po nasazení aktualizace do aplikace prohlížeč načte aktualizované soubory pracovních procesů služby, aby zahájil proces aktualizace.

Překvapením mnoha vývojářů je, že i když se tato aktualizace dokončí, neprojeví se, dokud uživatel nepřejde na všech kartách. Nestačí aktualizovat kartu zobrazující aplikaci, i když se jedná o jedinou kartu, která aplikaci zobrazuje. Dokud se vaše aplikace úplně neskončí, zůstane nový pracovní proces služby v čekání na aktivaci stavu. To není specifické pro Blazor, ale spíše jde o standardní chování webové platformy.

To obvykle řeší potíže vývojářům, kteří se pokoušejí otestovat aktualizace pracovního procesu služby nebo offline prostředků uložených v mezipaměti. Pokud zkontrolujete vývojářské nástroje prohlížeče, může se zobrazit něco podobného:

Dokud seznam "klienti", které jsou karty nebo okna, které zobrazují vaši aplikaci, je neprázdné, pracovní proces pokračuje v čekání. Důvodem, proč to pracovníci služeb dělají, je zaručit konzistenci. Konzistence znamená, že všechny prostředky se načítají ze stejné atomické mezipaměti.

Při testování změn může být vhodné vybrat odkaz "skipWaiting", jak je znázorněno na předchozím snímku obrazovky, a pak stránku znovu načíst. Můžete to automatizovat pro všechny uživatele tím, že zakódujete pracovní proces služby, abyste přeskočí fázi čekání a okamžitě aktivovali aktualizaci. Pokud fázi čekání přeskočíte, dáváte záruku, že prostředky se vždy načítají konzistentně ze stejné instance mezipaměti.

Uživatelé můžou spouštět jakoukoli historickou verzi aplikace.

Vývojáři webu obvykle očekávají, že uživatelé spouštějí jenom nejnovější nasazenou verzi své webové aplikace, protože to je normální v rámci tradičního modelu distribuce webu. Offline aplikace PWA je ale spíše náčiní nativní mobilní aplikace, kde uživatelé nemusí nutně používat nejnovější verzi.

Jak je vysvětleno v části Aktualizace na pozadí, po nasazení aktualizace do aplikace bude každý existující uživatel nadále používat předchozí verzi pro alespoň jednu další návštěvu, protože aktualizace se vyskytuje na pozadí a není aktivovaná, dokud uživatel poté nepřejde pryč. Navíc použitá předchozí verze nemusí být nutně předchozí, kterou jste nasadili. Předchozí verze může být libovolná historická verze v závislosti na tom, kdy uživatel naposledy dokončil aktualizaci.

To může být problém, pokud front-endové a back-endové části vaší aplikace vyžadují smlouvu o schématu požadavků rozhraní API. Dokud nebudete mít jistotu, že všichni uživatelé upgradovali, nesmíte nasadit zpětně nekompatibilní změny schématu rozhraní API. Případně můžete uživatelům zablokovat používání nekompatibilních starších verzí aplikace. Tento požadavek na scénář je stejný jako u nativních mobilních aplikací. Pokud nasadíte zásadní změnu v serverových rozhraních API, klientská aplikace se přeruší pro uživatele, kteří ještě neaktualizovali.

Pokud je to možné, nenasazujte do back-endových rozhraní API zásadní změny. Pokud to musíte udělat, zvažte použití standardních rozhraní API service workerů, jako je ServiceWorkerRegistration , abyste zjistili, jestli je aplikace aktuální, a pokud ne, aby se zabránilo použití.

Interference se stránkami vykreslenými serverem

Jak je popsáno v části Stránky vykreslené serverem podpory, pokud chcete obejít chování pracovního procesu služby vrácení /index.html obsahu pro všechny požadavky navigace, upravte logiku pracovního procesu služby.

Veškerý obsah manifestu prostředku pracovního procesu služby se ukládá do mezipaměti.

Jak je popsáno v části Ukládání prostředků řízení do mezipaměti , soubor service-worker-assets.js se vygeneruje během sestavování a vypíše všechny prostředky, které by měl pracovní proces služby načíst a uložit do mezipaměti.

Vzhledem k tomu, že tento seznam obsahuje vše, co se vygeneruje wwwroot, včetně obsahu dodaného externími balíčky a projekty, musíte být opatrní, abyste tam nevložili příliš mnoho obsahu. wwwroot Pokud adresář obsahuje miliony obrázků, pracovní proces služby se pokusí načíst a uložit je do mezipaměti, spotřebovávat nadměrnou šířku pásma a s největší pravděpodobností se úspěšně nedokončí.

Implementujte libovolnou logiku pro řízení, která podmnožina obsahu manifestu by se měla načíst a uložit do mezipaměti úpravou onInstall funkce v service-worker.published.js.

Interakce s ověřováním

Šablonu PWA lze použít ve spojení s ověřováním. PwA s podporou offline může také podporovat ověřování, pokud má uživatel počáteční síťové připojení.

Pokud uživatel nemá síťové připojení, nemůže se ověřit ani získat přístupové tokeny. Při pokusu o návštěvu přihlašovací stránky bez přístupu k síti se zobrazí zpráva "chyba sítě". Je nutné navrhnout tok uživatelského rozhraní, který uživateli umožňuje provádět užitečné úlohy v offline režimu, aniž by se pokusil uživatele ověřit nebo získat přístupové tokeny. Alternativně můžete navrhnout aplikaci tak, aby řádně selhala, když síť není dostupná. Pokud aplikace nemůže být navržená tak, aby tyto scénáře zpracovávala, možná nebudete chtít povolit offline podporu.

Když je aplikace navržená pro online a offline použití znovu online:

• Aplikace může potřebovat zřídit nový přístupový token.
• Aplikace musí zjistit, jestli je k této službě přihlášen jiný uživatel, aby mohl použít operace na účet uživatele, který byl proveden, když byl offline.

Vytvoření offline aplikace PWA, která komunikuje s ověřováním:

• AccountClaimsPrincipalFactory<TAccount> Nahraďte továrnou, která ukládá poslední přihlášeného uživatele a používá uloženého uživatele, když je aplikace offline.
• Za frontue operace, když je aplikace offline, a použít je, když aplikace vrátí online.
• Během odhlášení vymažte uloženého uživatele.

Ukázková CarChecker aplikace ukazuje předchozí přístupy. Podívejte se na následující části aplikace:

• OfflineAccountClaimsPrincipalFactory (Client/Data/OfflineAccountClaimsPrincipalFactory.cs)
• LocalVehiclesStore (Client/Data/LocalVehiclesStore.cs)
• LoginStatus component (Client/Shared/LoginStatus.razor)

Další materiály

• Řešení potíží se skriptem PowerShellu pro integritu
• Vyjednávání mezi zdroji na straně SignalR klienta pro ověřování