Poruchy ukládání do vyrovnávací paměti balíčků a kontroly integrity v ASP.NET Core Blazor WebAssembly .NET

Tento článek vysvětluje ukládání prostředků do mezipaměti pro Blazor WebAssembly a jak diagnostikovat a řešit selhání integrity.

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
• .NET prostředí a sestavení
• Data specifická pro národní prostředí

Konfigurace spuštění Blazor, vložená do dotnet.js souboru, obsahuje otisk prstu manifestu souborů, které tvoří aplikaci a které je třeba stáhnout spolu s hash každého souboru. Soubory aplikace se předem načtou a ukládají do mezipaměti v prohlížeči.

Poznámka:

†In .NET 10 nebo novější soubor manifestu blazor.boot.json už neexistuje. Pokud upgradujete aplikaci, která spoléhá na soubor manifestu pro vlastní zpracování, doporučujeme shromažďovat informace přímo z sestavení.

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. Hodnoty hash souborů v mezipaměti se porovnávají s hodnotami hash v konfiguraci spouštění. Prohlížeč vygeneruje chybu, pokud se nezdaří kontrola integrity staženého souboru.

Další informace najdete v následujících částech článku Základy: Statické soubory :

• Statické prostředky předem načtené Blazor architektury
• Otiskněte statické prostředky na straně klienta v samostatných Blazor WebAssembly aplikacích

Blazoralgoritmus pro správu integrity souborů:

• Zajišťuje, že aplikace nezpůsobí riziko načtení nekonzistentní sady souborů, například pokud je na webový server nasazena nová verze, 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ádal nekonzistentní nebo neplatné odpovědi serveru, což může zabránit spuštění aplikace, přestože uživatel stránku zkusí aktualizovat 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 platný digest v atributu 'integrity' pro prostředek 'https://myapp.example.com/_framework/MyBlazorApp.dll' s 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.

Blazor WebAssemblyReferenční zdroj spouštění najdete Boot.WebAssembly.ts v souboru v dotnet/aspnetcore úložišti GitHub.

Poznámka:

Odkazy na referenční zdroj .NET v dokumentaci obvykle otevřou výchozí větev úložiště, která představuje aktuální vývoj další verze .NET. Chcete-li vybrat značku pro konkrétní vydání, použijte rozbalovací nabídku Přepnout větve nebo značky. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Diagnostikovat problémy s integritou

Když je aplikace sestavená, vygenerovaný spouštěcí manifest popisuje hodnoty hash SHA-256 spouštěcích prostředků v době vytvoření výstupu sestavení. Kontrola integrity projde tak dlouho, dokud hodnoty hash SHA-256 v manifestu spouštění odpovídají 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 k sestavení ručně upravujete 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 k tomu, abyste zpracovali artefakty sestavení jako binary soubory.
  • 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.
• Manifest spuštění 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, který je třeba diagnostikovat.

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. K prošetření tohoto:

• 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). Je v pořádku, když webový server implementuje kompresi HTTP (například vrací content-encoding: br nebo content-encoding: gzip), protože to nemá vliv na výsledek po dekompresi. Není v pořádku, aby webový server upravil nekomprimovaná data.

Zakázání kontroly integrity pro aplikace 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, ručně načtěte spouštěcí prostředky na straně klienta a vyhněte se předání integrity parametru volání fetch .

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áno deaktivování kontroly integrity. Servery můžou odpovědět na požadavek libovolným způsobem mimo rozsah Blazor architektury. Architektura umožňuje předchozímu přístupu, aby aplikace běžela 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 nelze 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í kontroly integrity pro 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.