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

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.

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í.

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

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

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ží.

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