Megosztás a következőn keresztül:

ASP.NET Core Blazor WebAssembly .NET-csomag gyorsítótárazási és integritás-ellenőrzési hibái

Megjegyzés

Ez nem a cikk legújabb verziója. Az aktuális kiadásról a cikk .NET 10-es verziójában olvashat.

Figyelmeztetés

A ASP.NET Core ezen verziója már nem támogatott. További információt a .NET és a .NET Core támogatási szabályzatában talál. Az aktuális kiadásról a cikk .NET 10-es verziójában olvashat.

Ez a cikk ismerteti az eszközök gyorsítótárazását Blazor WebAssembly , valamint az integritási hibák diagnosztizálását és megoldását.

Amikor egy Blazor WebAssembly alkalmazás betöltődik a böngészőben, az alkalmazás letölti a rendszerindító erőforrásokat a kiszolgálóról:

  • JavaScript-kód az alkalmazás elindításához
  • .NET-futtatókörnyezet és összetevők
  • Helyspecifikus adatok

A Blazor rendszerindítási konfiguráció, amely be van ágyazva dotnet.js, tartalmazza az alkalmazást alkotó fájlok ujjlenyomattal ellátott jegyzékét, valamint az egyes fájlok tartalmának kivonatát. Az alkalmazás fájljait a böngésző előre betölti és gyorsítótárazza.

Megjegyzés

† .NET 10 vagy újabb verziójában a blazor.boot.json jegyzékfájl már nem található. Ha olyan alkalmazást frissít, amely a jegyzékfájlra támaszkodik egyéni feldolgozásra, javasoljuk, hogy közvetlenül a buildből gyűjtse össze az információkat.

Amikor Blazor WebAssembly letölti az alkalmazás indítási fájljait, arra utasítja a böngészőt, hogy végezzen integritás-ellenőrzéseket a válaszokon. Blazor SHA-256 kivonatértékeket küld a DLL(.dll), a WebAssembly (.wasm) és más fájlok számára. A gyorsítótárazott fájlok fájlkivonatai a rendszerindítási konfigurációban lévő kivonatokkal vannak összehasonlítva. A böngésző hibát okoz, ha valamelyik letöltött fájl integritás-ellenőrzése sikertelen.

További információkért tekintse meg az Alapok: Statikus fájlok című cikk alábbi szakaszait:

A rendszerindítási Blazor jegyzékfájl (blazor.boot.json) kivételével a WebAssembly .NET-futtatókörnyezetet és az alkalmazáscsomagfájlokat gyorsítótárazza a klienseken. A Blazor rendszerindítási konfiguráció tartalmazza az alkalmazást alkotó fájlok jegyzékfájlját, valamint a fájl tartalmának kivonatát, amely alapján megállapíthatja, hogy a rendszerindítási erőforrások bármelyike módosult-e. Blazor gyorsítótárazza a letöltött fájlokat a böngésző Cache API-jának használatával.

Amikor Blazor WebAssembly letölti az alkalmazás indítási fájljait, arra utasítja a böngészőt, hogy végezzen integritás-ellenőrzéseket a válaszokon. BlazorSHA-256 kivonatértékeket küld a DLL(), a WebAssembly (.dll.wasm) és a Blazor rendszerindítási konfigurációban lévő egyéb fájlok számára, amelyek nem gyorsítótárazva vannak az ügyfeleken. A gyorsítótárazott fájlok fájlkivonatai a rendszerindítási konfigurációban lévő Blazor kivonatokkal vannak összehasonlítva. Az egyező kivonatot tartalmazó gyorsítótárazott fájlok esetében Blazor a gyorsítótárazott fájlokat használja. Ellenkező esetben a rendszer fájlokat kér a kiszolgálótól. A fájl letöltése után a rendszer ismét ellenőrzi a kivonatot az integritás ellenőrzéséhez. A böngésző hibát okoz, ha valamelyik letöltött fájl integritás-ellenőrzése sikertelen.

Blazor's algoritmus a fájlintegritás kezelésére:

  • Biztosítja, hogy az alkalmazás ne veszélyezhesse a fájlok inkonzisztens készletének betöltését, például ha a webkiszolgálóra új üzembe helyezést alkalmaz, miközben a felhasználó éppen tölti le az alkalmazásfájlokat. Az inkonzisztens fájlok hibás alkalmazáshoz vezethetnek.
  • Biztosítja, hogy a felhasználó böngészője soha ne gyorsítótárazza az inkonzisztens vagy érvénytelen válaszokat, ami megakadályozhatja, hogy az alkalmazás elinduljon még akkor is, ha a felhasználó manuálisan frissíti az oldalt.
  • Biztonságossá teszi a válaszok gyorsítótáraztatását, és nem ellenőrzi a kiszolgálóoldali módosításokat, amíg maguk a várt SHA-256 kivonatok nem változnak, így a további oldalbetöltések kevesebb kérést igényelnek, és gyorsabban befejeződnek.

Ha a webkiszolgáló olyan válaszokat ad vissza, amelyek nem felelnek meg a várt SHA-256 kivonatoknak, az alábbi példához hasonló hiba jelenik meg a böngésző fejlesztői konzolján:

Nem sikerült érvényes kivonatot találni az 'https://myapp.example.com/_framework/MyBlazorApp.dll' erőforrás 'integritás' attribútumában a számított SHA-256 integritással: 'IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY='. Az erőforrás le lett tiltva.

A legtöbb esetben a figyelmeztetés nem jelez integritás-ellenőrzéssel kapcsolatos problémát. Ehelyett a figyelmeztetés általában azt jelenti, hogy más probléma is létezik.

A Blazor WebAssembly rendszerindítási referenciaforrásához lásd a Boot.WebAssembly.ts fájlt a dotnet/aspnetcore GitHub-adattárban.

Megjegyzés

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. Ha ki szeretne jelölni egy címkét egy adott kiadáshoz, használja az Ágak vagy címkék váltása 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.

Integritási problémák diagnosztizálása

Az alkalmazás létrehozásakor a létrehozott rendszerindítási jegyzék leírja a rendszerindítási erőforrások SHA-256 kivonatait a build kimenetének létrehozásakor. Az integritás-ellenőrzés addig tart, amíg az SHA-256 kivonatok a rendszerindítási jegyzékben megegyeznek a böngészőbe kézbesített fájlokkal.

A sikertelenség gyakori okai a következők:

  • A webkiszolgáló válasza hiba (például 404 – Nem található vagy 500 belső kiszolgálóhiba) a böngésző által kért fájl helyett. Ezt a böngésző nem válaszhibaként, hanem integritásellenőrzési hibaként jelenti.
  • Valami megváltoztatta a fájlok tartalmát a fájlok összeállítása és a böngészőbe való kézbesítése között. Ez a következő esetekben fordulhat elő:
    • Ha ön vagy a buildelési eszközök manuálisan módosítják a build kimenetét.
    • Ha az üzembe helyezési folyamat egy része módosította a fájlokat. Ha például Egy Git-alapú üzembehelyezési mechanizmust használ, vegye figyelembe, hogy a Git transzparens módon alakítja át a Windows-stílusú vonalvégződéseket Unix-stílusú sorvégződésekké, ha fájlokat véglegesít a Windowson, és kijelentkezik a Linuxon. A fájlsorvégződések módosítása megváltoztatja az SHA-256 kivonatokat. A probléma elkerülése érdekében fontolja meg a build-artifaktumok fájlokként való kezelését.
    • A webkiszolgáló a szolgáltatás részeként módosítja a fájl tartalmát. Egyes tartalomterjesztési hálózatok (CDN-ek) például automatikusan megpróbálják minimalizálni a HTML-t, ezáltal módosítják azt. Előfordulhat, hogy le kell tiltania az ilyen funkciókat.
  • A rendszerindítási jegyzék nem töltődik be megfelelően, vagy nem megfelelően van gyorsítótárazva az ügyfélen. A gyakori okok közé tartoznak a következők:
    • Helytelenül konfigurált vagy hibásan működő egyéni fejlesztői kód.
    • Egy vagy több helytelenül konfigurált köztes gyorsítótár réteg.

Annak diagnosztizálásához, hogy ezek közül melyik vonatkozik az Ön esetében:

  1. Figyelje meg, hogy melyik fájl aktiválja a hibát a hibaüzenet elolvasásával.
  2. Nyissa meg a böngésző fejlesztői eszközeit, és keresse meg a Hálózat lapot. Szükség esetén töltse be újra a lapot a kérések és válaszok listájának megtekintéséhez. Keresse meg a listában a hibát kiváltó fájlt.
  3. Ellenőrizze a HTTP-állapotkódot a válaszban. Ha a kiszolgáló a 200 - OK (vagy egy másik 2xx állapotkód) kivételével bármit visszaad, akkor a kiszolgálóoldali problémát kell diagnosztizálnia. A 403-ás állapotkód például azt jelenti, hogy engedélyezési probléma van, míg az 500-ás állapotkód azt jelenti, hogy a kiszolgáló nem meghatározott módon meghiúsul. Az alkalmazás diagnosztizálásához és javításához tekintse meg a kiszolgálóoldali naplókat.
  4. Ha az állapotkód 200 – OK az erőforráshoz, tekintse meg a böngésző fejlesztői eszközeinek választartalmat, és ellenőrizze, hogy a tartalom megfelel-e a várt adatoknak. Például gyakori probléma az útválasztás helytelen konfigurálása, így a kérések más fájlok esetében is visszaadják a index.html adatokat. Győződjön meg arról, hogy a .wasm kérelmekre adott válaszok WebAssembly bináris fájlok, és hogy a .dll kérelmekre adott válaszok .NET-szerelvény bináris fájlok. Ha nem, akkor a kiszolgálóoldali útválasztási problémát diagnosztizálni kell.
  1. Figyelje meg, hogy melyik fájl aktiválja a hibát a hibaüzenet elolvasásával.
  2. Nyissa meg a böngésző fejlesztői eszközeit, és keresse meg a Hálózat lapot. Szükség esetén töltse be újra a lapot a kérések és válaszok listájának megtekintéséhez. Keresse meg a listában a hibát kiváltó fájlt.
  3. Ellenőrizze a HTTP-állapotkódot a válaszban. Ha a kiszolgáló a 200 - OK (vagy egy másik 2xx állapotkód) kivételével bármit visszaad, akkor a kiszolgálóoldali problémát kell diagnosztizálnia. A 403-ás állapotkód például azt jelenti, hogy engedélyezési probléma van, míg az 500-ás állapotkód azt jelenti, hogy a kiszolgáló nem meghatározott módon meghiúsul. Az alkalmazás diagnosztizálásához és javításához tekintse meg a kiszolgálóoldali naplókat.
  4. Ha az állapotkód 200 – OK az erőforráshoz, tekintse meg a böngésző fejlesztői eszközeinek választartalmat, és ellenőrizze, hogy a tartalom megfelel-e a várt adatoknak. Például gyakori probléma az útválasztás helytelen konfigurálása, így a kérések más fájlok esetében is visszaadják a index.html adatokat. Győződjön meg arról, hogy a .wasm kérelmekre adott válaszok WebAssembly bináris fájlok, és hogy a .dll kérelmekre adott válaszok .NET-szerelvény bináris fájlok. Ha nem, akkor a kiszolgálóoldali útválasztási problémát diagnosztizálni kell.
  5. Ellenőrizze az alkalmazás közzétett és üzembe helyezett kimenetét az integritási hibák elhárítása PowerShell-szkripttel.

Ha meggyőződik arról, hogy a kiszolgáló helyes adatokat ad vissza, a fájl összeállítása és kézbesítése között más módon kell módosítani a tartalmat. Ennek kivizsgálása:

  • Vizsgálja meg a buildelési eszközláncot és az üzembehelyezési mechanizmust abban az esetben, ha a fájlok létrehozása után módosítják a fájlokat. Erre példa az, amikor a Git átalakítja a fájlsorvégződéseket a korábban ismertetett módon.
  • Vizsgálja meg a webkiszolgáló vagy a CDN konfigurációját abban az esetben, ha a válaszok dinamikus módosítására vannak beállítva (például a HTML minimalizálása). A webkiszolgálónak nem árt HTTP-tömörítést implementálnia (például content-encoding: br vagy content-encoding: gzipvisszaadni), mivel ez nem befolyásolja a dekompresszió utáni eredményt. A tömörítetlen adatok módosítása azonban nem megfelelő a webkiszolgáló számára.

Integritási PowerShell-szkript hibaelhárítása

A integrity.ps1 PowerShell-szkripttel ellenőrizheti a közzétett és üzembe helyezett Blazor-alkalmazásokat. A szkript a PowerShell Core 7-hez vagy újabb verzióhoz érhető el kiindulópontként, ha az alkalmazás olyan integritási problémákkal rendelkezik, amelyeket a Blazor-keretrendszer nem tud azonosítani. Előfordulhat, hogy a szkript testreszabása szükséges az alkalmazásokhoz, például ha a PowerShell 7.2.0-s verziójánál később fut.

A szkript ellenőrzi a publish mappában lévő fájlokat, és letölti az üzembe helyezett alkalmazásból, hogy észlelje az integritáskivonatokat tartalmazó különböző jegyzékekben szereplő problémákat. Ezeknek az ellenőrzéseknek a leggyakoribb problémákat kell észlelnie:

  • A közzétett kimenetben lévő fájlt anélkül módosította, hogy felismerte volna.
  • Az alkalmazás nem lett megfelelően üzembe helyezve az üzembe helyezési célhelyen, vagy valami megváltozott az üzembehelyezési cél környezetében.
  • Az üzembe helyezett alkalmazás és az alkalmazás közzétételének kimenete között különbségek vannak.

A szkript meghívása a következő paranccsal egy PowerShell-parancshéjban:

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

Az alábbi példában a szkript végrehajtása helyileg futó alkalmazáson történik https://localhost:5001/:

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

Helykitöltők

  • {BASE URL}: Az üzembe helyezett alkalmazás URL-címe. Záró perjelre (/) van szükség.
  • {PUBLISH OUTPUT FOLDER}: Az alkalmazás publish mappájának vagy helyének elérési útja, ahol az alkalmazás üzembe helyezés céljából közzé van téve.

Megjegyzés

A GitHub-adattár klónozása dotnet/AspNetCore.Docs esetén előfordulhat, hogy a integrity.ps1 szkriptet a Bitdefender vagy egy másik, a rendszeren található vírusolvasó karanténba helyezi. A fájlt általában egy vírusolvasó heurisztikus vizsgálati technológiája csapdába ejti, amely csupán olyan mintákat keres a fájlokban, amelyek kártevők jelenlétét jelezhetik. Ha meg szeretné akadályozni, hogy a vírusszkenner karanténba helyezze a fájlt, adjon hozzá kivételt a vírusszkennerhez az adattár klónozása előtt. Az alábbi példa egy windowsos rendszer szkriptjének tipikus elérési útja. Módosítsa az elérési utat szükség szerint más rendszerekre. A {USER} helyőrző a felhasználó elérési út szegmense.

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

Figyelmeztetés: A vírusolvasó kivételeinek létrehozása veszélyes, és csak akkor szabad végrehajtani, ha biztos benne, hogy a fájl biztonságos.

A fájlok ellenőrzőösszegének egy érvényes ellenőrzőösszeg-értékhez való összehasonlítása nem garantálja a fájlok biztonságát, de a fájlok olyan módon történő módosítása, amely fenntartja az ellenőrzőösszeg értékét, nem triviális a rosszindulatú felhasználók számára. Ezért az ellenőrzőösszegek általános biztonsági megoldásként hasznosak. Hasonlítsa össze a helyi integrity.ps1 fájl ellenőrzőösszegét az alábbi értékek egyikével:

  • SHA256: 32c24cb667d79a701135cb72f6bae490d81703323f61b8af2c7e5e5dc0f0c2bb
  • MD5: 9cee7d7ec86ee809a329b5406fbf21a8

Szerezze be a fájl ellenőrzőösszegét Windows operációs rendszeren az alábbi paranccsal. Adja meg a {PATH AND FILE NAME} helyőrző elérési útját és fájlnevét, és adja meg a {SHA512|MD5} helyőrzőhöz létrehozandó ellenőrzőösszeg típusát, SHA256 vagy MD5:

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

Ha aggódik amiatt, hogy az ellenőrzőösszeg-ellenőrzés nem elég biztonságos az ön környezetében, útmutatásért forduljon a szervezet biztonsági vezetéséhez.

További információ: A Microsoft Defender víruskereső fenyegetésvédelmének áttekintése.

Nem PWA-alkalmazások integritás-ellenőrzésének letiltása

A legtöbb esetben ne tiltsa le az integritás-ellenőrzést. Az integritás-ellenőrzés letiltása nem oldja meg azt a problémát, amely a váratlan válaszokat okozta, és a korábban felsorolt előnyök elvesztését eredményezi.

Előfordulhatnak olyan esetek, amikor a webkiszolgálóra nem lehet megbízható válaszok visszaküldésére támaszkodni, és nincs más lehetőség, mint ideiglenesen letiltani az integritás-ellenőrzéseket, amíg az alapul szolgáló probléma meg nem oldódik.

Az integritás-ellenőrzések letiltásához manuálisan töltse be az ügyféloldali rendszerindítási erőforrásokat , és ne adja át a integrity paramétert a fetch hívásnak.

Az integritás-ellenőrzések letiltásához adja hozzá a következőket egy tulajdonságcsoporthoz az Blazor WebAssembly alkalmazás projektfájljában (.csproj):

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResources emellett letiltja Blazor.dll, .wasmés más fájlok sha-256-kivonatok alapján történő gyorsítótárazásának alapértelmezett viselkedését, mert a tulajdonság azt jelzi, hogy az SHA-256 kivonatok nem támaszkodhatnak a helyességre. Még ebben a beállításban is előfordulhat, hogy a böngésző normál HTTP-gyorsítótára gyorsítótárazza ezeket a fájlokat, de ez a webkiszolgáló konfigurációjától és az általa kiszolgált cache-control fejléctől függ.

Megjegyzés

A BlazorCacheBootResources tulajdonság nem tiltja le a progresszív webalkalmazások (PWA-k) integritás-ellenőrzését. A PWA-kkal kapcsolatos útmutatásért tekintse meg a PWA-k integritás-ellenőrzésének letiltása című szakaszt .

Nem tudunk részletes listát adni azokról a forgatókönyvekről, ahol az integritás-ellenőrzés letiltása szükséges. A kiszolgálók a Blazor keretrendszer hatókörén kívül tetszőleges módon válaszolhatnak a kérésre. A keretrendszer lehetővé teszi, hogy az előző megközelítés lehetővé tegye az alkalmazás futtathatóvá tétele az alkalmazás által biztosított integritási garancia elvesztésének árán. Ismét nem javasoljuk az integritás-ellenőrzés letiltását, különösen a működési környezetekben. A fejlesztőknek meg kell oldaniuk a mögöttes integritási problémát, amely az integritás-ellenőrzés sikertelenségét okozza.

Néhány általános eset, amely integritási problémákat okozhat:

  • HTTP-n fut, ahol az integritás nem ellenőrizhető.
  • Ha az üzembehelyezési folyamat bármilyen módon módosítja a fájlokat a közzététel után.
  • Ha a szerver bármilyen módon módosítja a fájlokat.

A PWA-k integritás-ellenőrzésének letiltása

BlazorProgresszív webalkalmazás (PWA) sablonja egy javasolt service-worker.published.js fájlt tartalmaz, amely az alkalmazásfájlok offline használatra való lekéréséért és tárolásáért felelős. Ez egy külön folyamat a normál alkalmazásindítási mechanizmustól, és külön integritás-ellenőrzési logikával rendelkezik.

A service-worker.published.js fájlban a következő sor jelenik meg:

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

Az integritás-ellenőrzés letiltásához távolítsa el a integrity paramétert a sor alábbira módosításával:

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

Az integritás-ellenőrzés letiltása azt jelenti, hogy elveszíti az integritás-ellenőrzés által biztosított biztonsági garanciákat. Fennáll például a veszélye annak, hogy ha a felhasználó böngészője éppen az új verzió üzembe helyezésének pillanatában gyorsítótárazza az alkalmazást, az gyorsítótárazhat bizonyos fájlokat a régi telepítésből, néhányat pedig az új üzembe helyezésből. Ha ez történik, az alkalmazás hibás állapotba kerül, amíg egy további frissítést nem helyez üzembe.

  • Last updated on