Sdílet prostřednictvím

ASP.NET Core Blazor WebAssembly .NET Runtime a ukládání sady aplikací do mezipaměti

  • Článek

Poznámka:

Toto není nejnovější verze tohoto článku. Aktuální verzi najdete v tomto článku ve verzi .NET 9.

Upozorňující

Tato verze ASP.NET Core se už nepodporuje. Další informace najdete v zásadách podpory .NET a .NET Core. Aktuální verzi najdete v tomto článku ve verzi .NET 9.

Důležité

Tyto informace se týkají předběžného vydání produktu, který může být podstatně změněn před komerčním vydáním. Microsoft neposkytuje žádné záruky, výslovné ani předpokládané, týkající se zde uváděných informací.

Aktuální verzi najdete v tomto článku ve verzi .NET 9.

Když se Blazor WebAssembly aplikace načte v prohlížeči, aplikace stáhne spouštěcí prostředky ze serveru:

  • JavaScriptový kód pro spuštění aplikace
  • Modul runtime a sestavení .NET
  • Data specifická pro národní prostředí

BlazorS výjimkou souboru spouštěcích prostředků (blazor.boot.json), modul runtime WebAssembly .NET a soubory sady aplikací se ukládají do mezipaměti na klientech. Soubor blazor.boot.json obsahuje manifest souborů, které tvoří aplikaci, která se musí stáhnout, spolu s hodnotou hash obsahu souboru, který se používá ke zjištění, jestli se některé ze spouštěcích prostředků změnily. Blazorukládá stažené soubory do mezipaměti pomocí rozhraní API mezipaměti prohlížeče.

Když Blazor WebAssembly stáhne spouštěcí soubory aplikace, dá prohlížeči pokyn, aby u odpovědí provedl kontroly integrity. Blazor odesílá hodnoty hash SHA-256 pro knihovnu DLL (.dll), WebAssembly (.wasm) a další soubory v blazor.boot.json souboru. Hodnoty hash souborů uložených v mezipaměti se porovnávají s hodnotami hash v blazor.boot.json souboru. U souborů uložených v mezipaměti s odpovídající hodnotou hash Blazor se používá soubory uložené v mezipaměti. V opačném případě se ze serveru požadují soubory. Po stažení souboru se znovu zkontroluje jeho hodnota hash pro ověření integrity. Prohlížeč vygeneruje chybu, pokud se nezdaří kontrola integrity staženého souboru.

Blazoralgoritmus pro správu integrity souborů:

  • Zajišťuje, že aplikace neriskuje načtení nekonzistentní sady souborů, například pokud se na webový server použije nové nasazení, zatímco uživatel právě stahuje soubory aplikace. Nekonzistentní soubory můžou vést k nesprávné aplikaci.
  • Zajišťuje, aby prohlížeč uživatele nikdy neukládaly nekonzistentní nebo neplatné odpovědi, což může zabránit spuštění aplikace, i když uživatel stránku aktualizuje ručně.
  • Zajistí bezpečnost ukládání odpovědí do mezipaměti a nezkontroluje změny na straně serveru, dokud se očekávané hodnoty hash SHA-256 nezmění, takže následné načtení stránky zahrnuje méně požadavků a dokončí se rychleji.

Pokud webový server vrátí odpovědi, které neodpovídají očekávaným hodnotám hash SHA-256, zobrazí se v konzole pro vývojáře prohlížeče chyba podobná následujícímu příkladu:

Nepodařilo se najít platnou hodnotu hash v atributu integrity prostředku shttps://myapp.example.com/_framework/MyBlazorApp.dll vypočítanou integritou SHA-256 IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY=. Prostředek je zablokovaný.

Ve většině případů upozornění neoznačuje problém s kontrolou integrity. Místo toho upozornění obvykle znamená, že existuje nějaký jiný problém.

Poznámka:

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepnutí větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Diagnostika problémů integrity

Když je aplikace sestavená, vygenerovaný blazor.boot.json manifest popisuje hodnoty hash SHA-256 spouštěcích prostředků v době, kdy se vytvoří výstup sestavení. Kontrola integrity projde tak dlouho, dokud hodnoty hash SHA-256 odpovídají blazor.boot.json souborům doručeným do prohlížeče.

Mezi běžné důvody selhání patří:

  • Odpověď webového serveru je chyba (například 404 – Nenalezena nebo 500 – Vnitřní chyba serveru) místo požadovaného souboru v prohlížeči. Prohlížeč ho hlásí jako selhání kontroly integrity, a ne jako selhání odpovědi.
  • Něco změnilo obsah souborů mezi sestavením a doručením souborů do prohlížeče. Může k tomu dojít:
    • Pokud vy nebo nástroje sestavení ručně upravíte výstup sestavení.
    • Pokud některé aspekty procesu nasazení změnily soubory. Pokud například používáte mechanismus nasazení založený na Gitu, mějte na paměti, že Git transparentně převádí konce čar ve stylu Windows na konce čar ve stylu Unix, pokud potvrdíte soubory ve Windows a zkontrolujete je v Linuxu. Změna konce řádku souboru změní hodnoty hash SHA-256. Pokud se chcete tomuto problému vyhnout, zvažte použití .gitattributes ke zpracování artefaktů sestavení jako binary souborů.
    • Webový server upraví obsah souboru jako součást jejich poskytování. Například některé distribuční sítě obsahu (CDN) se automaticky pokusí minifikovat KÓD HTML, čímž ho upraví. Tyto funkce možná budete muset zakázat.
  • Soubor blazor.boot.json se nenačte správně nebo je nesprávně uložen v mezipaměti klienta. Mezi běžné příčiny patří:
    • Chybná konfigurace nebo selhání vlastního vývojářského kódu
    • Jedna nebo více chybně nakonfigurovaných mezilehlých vrstev ukládání do mezipaměti

Pokud chcete diagnostikovat, které z těchto možností platí ve vašem případě:

  1. Všimněte si, který soubor chybu aktivuje, čtením chybové zprávy.
  2. Otevřete vývojářské nástroje prohlížeče a podívejte se na kartu Síť . V případě potřeby stránku znovu načtěte, aby se zobrazil seznam požadavků a odpovědí. Najděte soubor, který v seznamu aktivuje chybu.
  3. Zkontrolujte stavový kód HTTP v odpovědi. Pokud server vrátí cokoli jiného než 200 – OK (nebo jiný stavový kód 2xx), máte k diagnostice problém na straně serveru. Stavový kód 403 například znamená problém s autorizací, zatímco stavový kód 500 znamená, že server selhává způsobem, který není zadaný. Pokud chcete diagnostikovat a opravit aplikaci, projděte si protokoly na straně serveru.
  4. Pokud je stavový kód 200 – OK prostředku, podívejte se na obsah odpovědi v vývojářských nástrojích prohlížeče a zkontrolujte, jestli obsah odpovídá očekávaným datům. Běžným problémem je například chybné konfigurace směrování tak, aby žádosti vracely vaše index.html data i pro jiné soubory. Ujistěte se, že odpovědi na .wasm požadavky jsou binární soubory WebAssembly a že odpovědi na .dll požadavky jsou binární soubory sestavení .NET. Pokud ne, máte problém se směrováním na straně serveru k diagnostice.
  5. Pomocí skriptu PowerShellu pro řešení potíží s integritou vyhledejte publikovaný a nasazený výstup aplikace.

Pokud potvrdíte, že server vrací důvěryhodně správná data, mezi sestavením a doručením souboru musí být něco jiného, co upravuje obsah. Prošetření:

  • Prozkoumejte sadu nástrojů sestavení a mechanismus nasazení v případě, že po sestavení souborů upravují soubory. Příkladem je, když Git transformuje konce řádků souboru, jak je popsáno výše.
  • Zkontrolujte konfiguraci webového serveru nebo CDN v případě, že jsou nastavené tak, aby dynamicky upravovali odpovědi (například při pokusu o minifikaci KÓDU HTML). Webový server je v pořádku implementovat kompresi HTTP (například vrácení content-encoding: br nebo content-encoding: gzip), protože to nemá vliv na výsledek po dekompresi. Není ale v pořádku, aby webový server upravil nekomprimovaná data.

Řešení potíží se skriptem PowerShellu pro integritu

Pomocí skriptu PowerShellu integrity.ps1 ověřte publikovanou a nasazenou Blazor aplikaci. Skript se poskytuje pro PowerShell Core 7 nebo novější jako výchozí bod, když má aplikace problémy s integritou, které Blazor architektura nedokáže identifikovat. Přizpůsobení skriptu může být vyžadováno pro vaše aplikace, včetně toho, jestli běží ve verzi PowerShellu novější než verze 7.2.0.

Skript zkontroluje soubory ve publish složce a stáhne z nasazené aplikace, aby zjistil problémy v různých manifestech obsahujících hodnoty hash integrity. Tyto kontroly by měly detekovat nejběžnější problémy:

  • Upravili jste soubor v publikovaném výstupu, aniž byste si ho uvědomili.
  • Aplikace nebyla správně nasazená do cíle nasazení nebo se v prostředí cíle nasazení změnila.
  • Mezi nasazenou aplikací a výstupem publikování aplikace existují rozdíly.

V příkazovém prostředí PowerShellu spusťte skript pomocí následujícího příkazu:

.\integrity.ps1 {BASE URL} {PUBLISH OUTPUT FOLDER}

V následujícím příkladu se skript spustí v místně spuštěné aplikaci na https://localhost:5001/adrese:

.\integrity.ps1 https://localhost:5001/ C:\TestApps\BlazorSample\bin\Release\net6.0\publish\

Zástupné symboly:

  • {BASE URL}: Adresa URL nasazené aplikace. Je vyžadován koncové lomítko (/).
  • {PUBLISH OUTPUT FOLDER}: Cesta ke složce nebo umístění aplikace publish , kde je aplikace publikovaná pro nasazení.

Poznámka:

Při klonování dotnet/AspNetCore.Docs úložiště integrity.ps1 GitHub může skript umístit do karantény Bitdefender nebo jiný virový skener, který je v systému. Soubor je obvykle zachycen heuristickým skenovací technologií antivirového skeneru, který pouze hledá vzory v souborech, které by mohly znamenat přítomnost malwaru. Chcete-li zabránit, aby virový skener v karanténě souboru, před klonováním úložiště přidejte do antivirového skeneru výjimku. Následující příklad představuje typickou cestu ke skriptu v systému Windows. Upravte cestu podle potřeby pro jiné systémy. Zástupný {USER} symbol je segment cesty uživatele.

C:\Users\{USER}\Documents\GitHub\AspNetCore.Docs\aspnetcore\blazor\host-and-deploy\webassembly\_samples\integrity.ps1

Upozornění: Vytváření výjimek antivirového skeneru je nebezpečné a mělo by se provést pouze v případě, že jste si jisti, že je soubor bezpečný.

Porovnání kontrolního součtu souboru s platnou hodnotou kontrolního součtu nezaručuje bezpečnost souborů, ale úprava souboru způsobem, který udržuje hodnotu kontrolního součtu, není pro uživatele se zlými úmysly triviální. Kontrolní součty jsou proto užitečné jako obecný přístup k zabezpečení. Porovnejte kontrolní součet místního integrity.ps1 souboru s jednou z následujících hodnot:

  • SHA256: 32c24cb667d79a701135cb72f6bae490d81703323f61b8af2c7e5e5dc0f0c2bb
  • MD5: 9cee7d7ec86ee809a329b5406fbf21a8

Pomocí následujícího příkazu získejte kontrolní součet souboru v operačním systému Windows. Zadejte cestu a název souboru zástupného symbolu {PATH AND FILE NAME} a uveďte typ kontrolního součtu {SHA512|MD5} , který se má pro zástupný symbol vytvořit, nebo SHA256 MD5:

CertUtil -hashfile {PATH AND FILE NAME} {SHA256|MD5}

Pokud máte nějaké obavy, že ověření kontrolního součtu není ve vašem prostředí dostatečně zabezpečené, projděte si pokyny ve vedení vaší organizace v oblasti zabezpečení.

Další informace najdete v tématu Přehled ochrany před hrozbami podle Antivirová ochrana v programu Microsoft Defender.

Zákaz ukládání prostředků do mezipaměti a kontroly integrity u aplikací bez PWA

Ve většině případů nezakazujte kontrolu integrity. Zakázání kontroly integrity nevyřeší základní problém, který způsobil neočekávané odpovědi a výsledkem je ztráta dříve uvedených výhod.

V případech, kdy se webový server nedá spoléhat na vrácení konzistentních odpovědí a nemáte na výběr, ale dočasně zakázat kontroly integrity, dokud se nevyřeší základní problém.

Pokud chcete zakázat kontroly integrity, přidejte následující položky do skupiny vlastností v Blazor WebAssembly souboru projektu aplikace (.csproj):

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResources také zakáže Blazorvýchozí chování ukládání do mezipaměti .dll, .wasma další soubory na základě jejich hash SHA-256, protože vlastnost označuje, že hodnoty hash SHA-256 nelze spoléhat na správnost. I při tomto nastavení může normální mezipaměť HTTP prohlížeče tyto soubory ukládat do mezipaměti, ale to, jestli k tomu dojde, závisí na konfiguraci webového serveru a cache-control hlavičkách, které slouží.

Poznámka:

Tato BlazorCacheBootResources vlastnost nezakazuje kontroly integrity progresivních webových aplikací (PWA). Pokyny týkající se PWA najdete v části Zakázání kontroly integrity aplikace PWA.

Nemůžeme poskytnout úplný seznam scénářů, ve kterých je vyžadována kontrola integrity. Servery můžou odpovědět na požadavek libovolným způsobem mimo rozsah Blazor architektury. Architektura poskytuje BlazorCacheBootResources nastavení, které aplikaci umožní spustit za cenu ztráty záruky integrity, kterou může aplikace poskytnout. Opět nedoporučujeme zakázat kontrolu integrity, zejména pro produkční nasazení. Vývojáři by se měli snažit vyřešit základní problém integrity, který způsobuje selhání kontroly integrity.

Mezi obecné případy, které můžou způsobit problémy s integritou, patří:

  • Běží na http, kde nejde zkontrolovat integritu.
  • Pokud proces nasazení změní soubory po publikování jakýmkoli způsobem.
  • Pokud váš hostitel soubory nějakým způsobem upraví.

Zakázání ukládání prostředků do mezipaměti a kontroly integrity u PWA

BlazorŠablona progresivní webové aplikace (PWA) obsahuje navrhovaný service-worker.published.js soubor, který je zodpovědný za načítání a ukládání souborů aplikací pro offline použití. Jedná se o samostatný proces od normálního spouštěcího mechanismu aplikace a má vlastní samostatnou logiku kontroly integrity.

service-worker.published.js Uvnitř souboru je k dispozici následující řádek:

.map(asset => new Request(asset.url, { integrity: asset.hash }));

Chcete-li zakázat kontrolu integrity, odeberte integrity parametr změnou řádku na následující:

.map(asset => new Request(asset.url));

Zákaz kontroly integrity opět znamená, že ztratíte bezpečnostní záruky nabízené kontrolou integrity. Existuje například riziko, že pokud prohlížeč uživatele ukládá aplikaci do mezipaměti v přesně okamžiku, kdy nasadíte novou verzi, může ukládat některé soubory ze starého nasazení do mezipaměti a některé z nových nasazení. Pokud k tomu dojde, aplikace se zasekne v nefunkčním stavu, dokud nenasadíte další aktualizaci.

Další materiály

Načítání spouštěcího prostředku