Hostování a nasazení aplikací ASP.NET Core Blazor WebAssembly

Tento článek vysvětluje, jak hostovat a nasazovat Blazor WebAssembly pomocí služby ASP.NET Core, Content Delivery Networks (CDN), souborových serverů a stránek GitHubu.

S modelem Blazor WebAssemblyhostování:

• Aplikace Blazor , její závislosti a modul runtime .NET se stáhnou paralelně do prohlížeče.
• Aplikace se spustí přímo ve vlákně uživatelského rozhraní prohlížeče.

Tento článek se týká scénáře nasazení, ve kterém Blazor je aplikace umístěná na statickém hostitelském webovém serveru nebo službě, .NET se nepoužívá k poskytování Blazor aplikace. Tato strategie je popsána v části Samostatné nasazení , která obsahuje informace o hostování Blazor WebAssembly aplikace jako dílčí aplikace SLUŽBY IIS.

Subdoména a hostitel sub-aplikace IIS

Hostování subdomény nevyžaduje zvláštní konfiguraci aplikace. Pro hostování aplikace v subdoméně nemusítewwwroot/index.html

Hostování dílčích aplikací služby IIS vyžaduje , abyste nastavili základní cestu aplikace. Další informace a křížové odkazy na další pokyny k hostování dílčích aplikací služby IIS naleznete v tématu Hostitel a nasazení ASP.NET Core Blazor.

Zmenšení maximální velikosti haldy u některých prohlížečů mobilních zařízení

Při vytváření Blazor aplikace, která běží na klientovi (.Client projektu Blazor Web App samostatné Blazor WebAssembly aplikace) a cílí na prohlížeče mobilních zařízení, zejména Safari v iOSu, může být vyžadováno snížení maximální paměti aplikace s vlastností EmccMaximumHeapSize MSBuild. Výchozí hodnota je 2 147 483 648 bajtů, což může být příliš velké a může dojít k chybovému ukončení aplikace v případě, že se aplikace pokusí přidělit více paměti v prohlížeči, který mu neudělí. Následující příklad nastaví hodnotu na 268 435 456 bajtů v Program souboru:

<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>

Další informace o vlastnostech a cílech nástroje Mono/WebAssembly MSBuild najdete v tématu WasmApp.Common.targets (dotnet/runtime úložiště GitHub).

Formát balení webového vzorníku pro sestavení .NET

Webcil je webový formát balení pro sestavení .NET navržený tak, aby umožňoval použití Blazor WebAssembly v omezujících síťových prostředích. Soubory webcilu používají standardní obálku WebAssembly, kde jsou sestavení nasazena jako soubory WebAssembly, které používají standardní .wasm příponu souboru.

Webcil je výchozí formát balení při publikování Blazor WebAssembly aplikace. Chcete-li zakázat použití webového vzorníku, nastavte v souboru projektu aplikace následující vlastnost MSBuild:

<PropertyGroup>
  <WasmEnableWebcil>false</WasmEnableWebcil>
</PropertyGroup>

Přizpůsobení způsobu načítání spouštěcích prostředků

Přizpůsobte, jak se spouštěcí prostředky načítají pomocí loadBootResource rozhraní API. Další informace najdete v tématu Blazor core.

Komprese

Blazor WebAssembly Když je aplikace publikovaná, výstup se během publikování staticky komprimuje, aby se snížila velikost aplikace a odstranila režijní náklady na kompresi za běhu. Používají se následující algoritmy komprese:

• Brotli (nejvyšší úroveň)
• Gzip

Blazor spoléhá na hostitele, aby obsluhoval příslušné komprimované soubory. Při hostování Blazor WebAssembly samostatné aplikace může být potřeba další práce, aby se zajistilo, že se budou obsluhovat staticky komprimované soubory:

• Informace o konfiguraci komprese služby IIS web.config naleznete v části Iis: Brotli a Gzip compression section.
• Při hostování na statických hostitelských řešeních, která nepodporují staticky komprimované vyjednávání obsahu souborů, zvažte konfiguraci aplikace pro načtení a dekódování komprimovaných souborů Brotli:

Získejte dekodér JavaScript Brotli z google/brotli úložiště GitHub. Minifikovaný soubor dekodéru se jmenuje decode.min.js a nachází se ve složcejs.

Poznámka:

Pokud minifikovaná verze decode.js skriptu (decode.min.js) selže, zkuste místo toho použít neminifikovanou verzi (decode.js).

Aktualizujte aplikaci tak, aby používala dekodér.

wwwroot/index.html V souboru nastavte autostart na falseBlazorznačku ' s<script>:

<script src="_framework/blazor.webassembly.js" autostart="false"></script>

Blazor Za <script>značku a před koncovou </body> značku přidejte následující blok kódu <script> JavaScriptu. Následující funkce volá fetch s cache: 'no-cache', aby se mezipaměť prohlížeče aktualizovala.

Blazor Web App:

<script type="module">
  import { BrotliDecode } from './decode.min.js';
  Blazor.start({
    webAssembly: {
      loadBootResource: function (type, name, defaultUri, integrity) {
        if (type !== 'dotnetjs' && location.hostname !== 'localhost' && type !== 'configuration' && type !== 'manifest') {
          return (async function () {
            const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
            if (!response.ok) {
              throw new Error(response.statusText);
            }
            const originalResponseBuffer = await response.arrayBuffer();
            const originalResponseArray = new Int8Array(originalResponseBuffer);
            const decompressedResponseArray = BrotliDecode(originalResponseArray);
            const contentType = type === 
              'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
            return new Response(decompressedResponseArray, 
              { headers: { 'content-type': contentType } });
          })();
        }
      }
    }
  });
</script>

Samostatné Blazor WebAssembly:

<script type="module">
  import { BrotliDecode } from './decode.min.js';
  Blazor.start({
    loadBootResource: function (type, name, defaultUri, integrity) {
      if (type !== 'dotnetjs' && location.hostname !== 'localhost' && type !== 'configuration') {
        return (async function () {
          const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
          if (!response.ok) {
            throw new Error(response.statusText);
          }
          const originalResponseBuffer = await response.arrayBuffer();
          const originalResponseArray = new Int8Array(originalResponseBuffer);
          const decompressedResponseArray = BrotliDecode(originalResponseArray);
          const contentType = type === 
            'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
          return new Response(decompressedResponseArray, 
            { headers: { 'content-type': contentType } });
        })();
      }
    }
  });
</script>

Další informace o načítání spouštěcích prostředků najdete v tématu Blazor Core.

Pokud chcete zakázat kompresi, přidejte CompressionEnabled do souboru projektu aplikace vlastnost MSBuild a nastavte hodnotu na false:

<PropertyGroup>
  <CompressionEnabled>false</CompressionEnabled>
</PropertyGroup>

CompressionEnabled Vlastnost lze předat dotnet publish příkazu s následující syntaxí v příkazovém prostředí:

dotnet publish -p:CompressionEnabled=false

Přepsání adres URL pro správné směrování

Žádosti o směrování pro součásti stránek v Blazor WebAssembly aplikaci nejsou tak jednoduché jako žádosti o směrování v Blazor Server aplikaci. Blazor WebAssembly Zvažte aplikaci se dvěma komponentami:

• Main.razor: Načte se v kořenovém adresáři aplikace a obsahuje odkaz na komponentu About (href="About").
• About.razor: About součást.

Když se požaduje výchozí dokument aplikace pomocí adresního řádku prohlížeče (například https://www.contoso.com/):

1. Prohlížeč odešle žádost.
2. Vrátí se výchozí stránka, což je obvykle index.html.
3. index.html bootstraps the app.
4. Router komponenta se načte a komponenta RazorMain se vykreslí.

Na hlavní stránce vyberete odkaz na komponentu About , která funguje na klientovi, protože Blazor směrovač zastaví prohlížeč v tom, aby www.contoso.comAbout na internetu udělal požadavek a obsluhuje samotnou vykreslovanou About komponentu. Všechny požadavky na interní koncové body v aplikaci Blazor WebAssembly fungují stejným způsobem: Požadavky neaktivují žádosti na základě prohlížeče na prostředky hostované serverem na internetu. Směrovač zpracovává požadavky interně.

Pokud se žádost provede pomocí adresního řádku prohlížeče, www.contoso.com/Aboutpožadavek selže. Na internetovém hostiteli aplikace neexistuje žádný takový prostředek, takže se vrátí odpověď 404 – Nenalezena .

Vzhledem k tomu, že prohlížeče pořují požadavky na internetové hostitele na stránky na straně klienta, webové servery a hostitelské služby musí přepsat všechny požadavky na prostředky, které nejsou fyzicky na serveru na index.html stránce. Jakmile index.html se vrátí, směrovač aplikace Blazor převezme a odpoví správným prostředkem.

Při nasazování na server SLUŽBY IIS můžete použít modul pro přepsání adresy URL s publikovaným web.config souborem aplikace. Další informace najdete v části IIS .

Samostatné nasazení

Samostatné nasazení slouží Blazor WebAssembly aplikaci jako sada statických souborů, které jsou požadovány přímo klienty. Aplikace může obsluhovat Blazor jakýkoli statický souborový server.

Samostatné prostředky nasazení se publikují do složky /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot nebo bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish\ do složky (v závislosti na používané verzi sady .NET SDK), kde {TARGET FRAMEWORK} zástupný symbol představuje cílovou architekturu.

Azure App Service

Blazor WebAssemblyaplikace je možné nasadit do služby Aplikace Azure Services ve Windows, které hostuje aplikaci ve službě IIS.

Nasazení samostatné Blazor WebAssembly aplikace do služby Aplikace Azure Service pro Linux se v současné době nepodporuje. Doporučujeme hostovat samostatnou Blazor WebAssembly aplikaci pomocí Azure Static Web Apps, která tento scénář podporuje.

Azure Static Web Apps

K nasazení Blazor WebAssembly aplikace do Azure Static Web Apps použijte jeden z následujících přístupů:

• Nasazení ze sady Visual Studio
• Nasazení z editoru Visual Studio Code
• Nasazení z GitHubu

Nasazení ze sady Visual Studio

Pokud chcete nasadit ze sady Visual Studio, vytvořte profil publikování pro Azure Static Web Apps:

1. Uložte všechny neuložené práce v projektu, protože během procesu může být vyžadováno restartování sady Visual Studio.

2. V uživatelském rozhraní pro publikování sady Visual Studio vyberte Cílové>cílové azure>>Static Web Apps a vytvořte profil publikování.

3. Pokud není nainstalovaná komponenta Azure WebJobs Tools pro Visual Studio, zobrazí se výzva k instalaci komponenty pro ASP.NET a vývoj webu. Podle pokynů nainstalujte nástroje pomocí Instalační program pro Visual Studio. Visual Studio se při instalaci nástrojů automaticky zavře a znovu otevře. Po instalaci nástrojů začněte od prvního kroku a vytvořte profil publikování.

4. V konfiguraci profilu publikování zadejte název předplatného. Vyberte existující instanci nebo vyberte Vytvořit novou instanci. Při vytváření nové instance v uživatelském rozhraní vytvořit statickou webovou aplikaci na webu Azure Portal nastavte zdroj podrobností>nasazení na jiný. Než budete pokračovat, počkejte na dokončení nasazení na webu Azure Portal.

5. V konfiguraci profilu publikování vyberte instanci Azure Static Web Apps ze skupiny prostředků instance. Výběrem možnosti Dokončit vytvořte profil publikování. Pokud visual Studio vyzve k instalaci rozhraní příkazového řádku Static Web Apps (SWA), nainstalujte rozhraní příkazového řádku podle pokynů. Rozhraní příkazového řádku SWA vyžaduje NPM/Node.js (Dokumentace k sadě Visual Studio).

Po vytvoření profilu publikování nasaďte aplikaci do instance Azure Static Web Apps pomocí profilu publikování výběrem tlačítka Publikovat .

Nasazení z editoru Visual Studio Code

Pokud chcete nasadit z editoru Visual Studio Code, přečtěte si článek Rychlý start: Vytvoření prvního statického webu pomocí Azure Static Web Apps.

Nasazení z GitHubu

Pokud chcete nasadit z úložiště GitHub, přečtěte si kurz : Vytvoření statické webové aplikace v Blazor Azure Static Web Apps.

IIS

Služba IIS je pro aplikace schopný statický souborový server Blazor . Informace o konfiguraci služby IIS pro hostování Blazornajdete v tématu Vytvoření statického webu ve službě IIS.

Publikované prostředky se vytvářejí v /bin/Release/{TARGET FRAMEWORK}/publishbin\Release\{TARGET FRAMEWORK}\browser-wasm\publish závislosti na používané verzi sady SDK a umístění {TARGET FRAMEWORK} zástupného symbolu cílové architektury. Hostujte obsah publish složky na webovém serveru nebo hostitelské službě.

web.config

Blazor Při publikování web.config projektu se vytvoří soubor s následující konfigurací služby IIS:

• typy MIME
• Komprese HTTP je povolená pro následující typy MIME:
  • application/octet-stream
  • application/wasm
• Navazují se pravidla modulu přepsání adresy URL:
  • Obsluha podadresáři, ve kterém se nacházejí statické prostředky aplikace (wwwroot/{PATH REQUESTED}).
  • Vytvořte náhradní směrování SPA tak, aby se požadavky na jiné prostředky než soubor přesměrovaly do výchozího dokumentu aplikace ve složce statických prostředků (wwwroot/index.html).

Použití vlastního web.config

Použití vlastního web.config souboru:

1. Umístěte vlastní web.config soubor do kořenové složky projektu.
2. Publikujte projekt. Další informace najdete v tématu Hostitel a nasazení ASP.NET Core Blazor.

Pokud generování nebo transformace sady SDK web.config během publikování buď nepřesune soubor do publikovaných prostředků ve publish složce nebo upraví vlastní konfiguraci ve vašem vlastním web.config souboru, použijte k úplnému řízení procesu některý z následujících přístupů:

• Pokud sada SDK soubor negeneruje, například v samostatné aplikaci v závislosti na tom, ve které verzi sady SDK se používá a kde Blazor WebAssembly je zástupný symbol cílovou architekturou, nastavte /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot vlastnost v bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish souboru projektu ({TARGET FRAMEWORK}).<PublishIISAssets>true.csproj U samostatných aplikací WebAssembly se obvykle jedná o jediné požadované nastavení pro přesunutí vlastního web.config souboru a zabránění transformaci souboru sadou SDK.

  <PropertyGroup>
    <PublishIISAssets>true</PublishIISAssets>
  </PropertyGroup>
  

• Zakažte transformaci sady SDK web.config v souboru projektu (.csproj):

  <PropertyGroup>
    <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
  </PropertyGroup>
  

• Přidejte vlastní cíl do souboru projektu (.csproj) pro přesunutí vlastního web.config souboru. V následujícím příkladu je vlastní web.config soubor umístěn vývojářem v kořenovém adresáři projektu. Pokud se web.config soubor nachází jinde, zadejte cestu k souboru v souboru .SourceFiles Následující příklad určuje publish složku s $(PublishDir), ale zadejte cestu k DestinationFolder vlastní výstupní umístění.

  <Target Name="CopyWebConfig" AfterTargets="Publish">
    <Copy SourceFiles="web.config" DestinationFolder="$(PublishDir)" />
  </Target>
  

Instalace modulu pro přepsání adresy URL

K přepsání adres URL se vyžaduje modul pro přepsání adres URL. Modul není ve výchozím nastavení nainstalovaný a není k dispozici pro instalaci jako funkce služby role Webový server (IIS). Modul se musí stáhnout z webu služby IIS. Pomocí instalačního programu webové platformy nainstalujte modul:

1. Místně přejděte na stránku pro stažení modulu pro přepsání adresy URL. Pro anglickou verzi vyberte WebPI a stáhněte instalační program WebPI. V případě jiných jazyků vyberte příslušnou architekturu pro server (x86/x64) a stáhněte instalační program.
2. Zkopírujte instalační program na server. Spusťte instalační program. Vyberte tlačítko Instalovat a přijměte licenční podmínky. Po dokončení instalace se nevyžaduje restartování serveru.

Konfigurace webu

Nastavte fyzickou cestu webu ke složce aplikace. Složka obsahuje:

• Soubor web.config , který služba IIS používá ke konfiguraci webu, včetně požadovaných pravidel přesměrování a typů obsahu souborů.
• Složka statického prostředku aplikace.

Hostování jako dílčí aplikace SLUŽBY IIS

Pokud je samostatná aplikace hostovaná jako dílčí aplikace služby IIS, proveďte jednu z následujících akcí:

• Zakažte zděděnou obslužnou rutinu modulu ASP.NET Core.

  Odeberte obslužnou rutinu v Blazor publikovaném web.config souboru aplikace přidáním <handlers> oddílu <system.webServer> do oddílu souboru:

  <handlers>
    <remove name="aspNetCore" />
  </handlers>
  

• Zakažte dědičnost oddílu kořenové (nadřazené) aplikace <system.webServer> pomocí elementu se <location> nastavenou inheritInChildApplications nafalse:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <handlers>
          <add name="aspNetCore" ... />
        </handlers>
        <aspNetCore ... />
      </system.webServer>
    </location>
  </configuration>
  

  Poznámka:

  Zakázání dědičnosti kořenové (nadřazené) části aplikace <system.webServer> je výchozí konfigurace publikovaných aplikací pomocí sady .NET SDK.

Kromě konfigurace základní cesty aplikace se provádí odebrání obslužné rutiny nebo zakázání dědičnosti. Nastavte základní cestu aplikace v souboru aplikace index.html na alias IIS použitý při konfiguraci dílčí aplikace ve službě IIS.

Základní cestu aplikace nakonfigurujte podle pokynů v článku Hostitel a nasaďte ASP.NET Core Blazor .

Komprese Brotli a Gzip

Tato část se týká jenom samostatných Blazor WebAssembly aplikací.

Službu IIS je možné nakonfigurovat tak web.config , aby obsluhovala komprimované Blazor prostředky Brotli nebo Gzip pro samostatné Blazor WebAssembly aplikace. Příklad konfiguračního souboru naleznete v tématu web.config.

V následujících scénářích může být vyžadována další konfigurace ukázkového web.config souboru:

• Specifikace aplikace volá jednu z následujících možností:
  • Obsluha komprimovaných souborů, které nejsou nakonfigurované ukázkovým web.config souborem.
  • Obsluha komprimovaných souborů nakonfigurovaných ukázkovým web.config souborem v nekomprimovaném formátu
• Konfigurace služby IIS serveru (například applicationHost.config) poskytuje výchozí hodnoty služby IIS na úrovni serveru. V závislosti na konfiguraci na úrovni serveru může aplikace vyžadovat jinou konfiguraci služby IIS, než jaký ukázkový web.config soubor obsahuje.

Další informace o vlastních web.config souborech najdete v části Použití vlastního web.config oddílu.

Řešení problému

Pokud se zobrazí chyba 500 – Vnitřní chyba serveru a Správce služby IIS při pokusu o přístup ke konfiguraci webu vyvolá chyby, ověřte, že je nainstalovaný modul pro přepsání adresy URL. Pokud modul není nainstalovaný, web.config nejde soubor analyzovat službou IIS. Tím zabráníte správci služby IIS načíst konfiguraci webu a web v poskytování Blazorstatických souborů.

Další informace o řešení potíží s nasazeními do služby IIS najdete v tématu Řešení potíží ASP.NET Core ve službě Aplikace Azure a službě IIS.

Azure Storage

Hostování statických souborů Azure Storage umožňuje hostování bezserverových Blazor aplikací. Podporují se vlastní názvy domén, Azure Content Delivery Network (CDN) a HTTPS.

Pokud je pro hostování statického webu v účtu úložiště povolená služba Blob Service:

• Nastavte název dokumentu rejstříku na index.htmlhodnotu .
• Nastavte cestu k dokumentu Chyba na index.htmlhodnotu . Razor komponenty a další koncové body, které nejsou soubory, se nenakládají na fyzických cestách ve statickém obsahu uloženém službou Blob Service. Když se zobrazí požadavek na jeden z těchto prostředků, který Blazor by měl směrovač zpracovat, chyba 404 – Nenalezena generovaná službou blob service směruje požadavek na cestu k dokumentu Chyba. Vrátí se index.html objekt blob a Blazor směrovač načte a zpracuje cestu.

Pokud se soubory nenačtou za běhu kvůli nevhodným typům MIME v hlavičce souborů Content-Type , proveďte jednu z následujících akcí:

• Nakonfigurujte nástroje tak, aby při nasazení souborů nastavily správné typy MIME (Content-Type hlavičky).

• Po nasazení aplikace změňte typy MIME (Content-Type hlavičky) pro soubory.

  V Průzkumník služby Storage (Azure Portal) pro každý soubor:

  1. Klikněte na soubor pravým tlačítkem a vyberte Vlastnosti.
  2. Nastavte contentType a vyberte tlačítko Uložit.

Další informace najdete v tématu Hostování statického webu ve službě Azure Storage.

Nginx

Následující nginx.conf soubor je zjednodušený a ukazuje, jak nakonfigurovat Nginx tak, aby soubor odesílal index.html , kdykoli nemůže najít odpovídající soubor na disku.

events { }
http {
    server {
        listen 80;

        location / {
            root      /usr/share/nginx/html;
            try_files $uri $uri/ /index.html =404;
        }
    }
}

Při nastavování limitu limit_reqBlazor WebAssemblyrychlosti nárazové rychlosti NGINX u aplikací můžou aplikace vyžadovat velkou burst hodnotu parametru, aby vyhovovala relativně velkému počtu požadavků provedených aplikací. Zpočátku nastavte hodnotu alespoň na 60:

http {
    server {
        ...

        location / {
            ...

            limit_req zone=one burst=60 nodelay;
        }
    }
}

Zvyšte hodnotu, pokud vývojářské nástroje prohlížeče nebo nástroj síťového provozu indikují, že požadavky dostávají stavový kód 503 – Služba není k dispozici .

Další informace o konfiguraci webového serveru Nginx v produkčním prostředí naleznete v tématu Vytváření konfiguračních souborů NGINX Plus a NGINX.

Apache

Blazor WebAssembly Nasazení aplikace do Apache:

1. Vytvořte konfigurační soubor Apache. Následující příklad je zjednodušený konfigurační soubor (blazorapp.config):

   <VirtualHost *:80>
       ServerName www.example.com
       ServerAlias *.example.com
   
       DocumentRoot "/var/www/blazorapp"
       ErrorDocument 404 /index.html
   
       AddType application/wasm .wasm
   
       <Directory "/var/www/blazorapp">
           Options -Indexes
           AllowOverride None
       </Directory>
   
       <IfModule mod_deflate.c>
           AddOutputFilterByType DEFLATE text/css
           AddOutputFilterByType DEFLATE application/javascript
           AddOutputFilterByType DEFLATE text/html
           AddOutputFilterByType DEFLATE application/octet-stream
           AddOutputFilterByType DEFLATE application/wasm
           <IfModule mod_setenvif.c>
               BrowserMatch ^Mozilla/4 gzip-only-text/html
               BrowserMatch ^Mozilla/4.0[678] no-gzip
               BrowserMatch bMSIE !no-gzip !gzip-only-text/html
           </IfModule>
       </IfModule>
   
       ErrorLog /var/log/httpd/blazorapp-error.log
       CustomLog /var/log/httpd/blazorapp-access.log common
   </VirtualHost>
   

1. Umístěte konfigurační soubor Apache do /etc/httpd/conf.d/ adresáře.

2. Umístěte publikované prostředky aplikace (/bin/Release/{TARGET FRAMEWORK}/publish/wwwrootkde {TARGET FRAMEWORK} zástupný symbol představuje cílovou architekturu) do /var/www/blazorapp adresáře (umístění určené v DocumentRoot konfiguračním souboru).

3. Restartujte službu Apache.

Další informace najdete v tématech mod_mime a mod_deflate.

Stránky GitHubu

Výchozí akce GitHubu, která nasazuje stránky, přeskočí nasazení složek začínajících podtržítkem, _framework například složky. Pokud chcete nasadit složky začínající podtržítkem, přidejte do větve Git prázdný .nojekyll soubor.

Git zpracovává soubory JavaScriptu (JS), jako blazor.webassembly.jsje text a převádí konce řádků z CRLF (kanál návratového řádku řádku) na LF (kanál řádku) v kanálu nasazení. Tyto změny v JS souborech vytvářejí různé hodnoty hash souborů, než Blazor se odesílají klientovi v blazor.boot.json souboru. Neshoda vede k selhání kontroly integrity v klientovi. Jedním z přístupů k vyřešení tohoto problému je přidání .gitattributes souboru s řádkem *.js binary před přidáním prostředků aplikace do větve Git. Řádek *.js binary nakonfiguruje Git tak, aby se soubory zpracovávaly JS jako binární soubory, což zabraňuje zpracování souborů v kanálu nasazení. Hodnoty hash souboru nezpracovaných souborů odpovídají položkám v blazor.boot.json souboru a úspěšné kontroly integrity na straně klienta. Další informace najdete v tématu ASP.NET Modulu runtime .NET Core Blazor WebAssembly a ukládání do mezipaměti sady aplikací.

Pokud chcete zpracovat přepsání adresy URL, přidejte wwwroot/404.html soubor se skriptem, který zpracovává přesměrování požadavku na index.html stránku. Příklad najdete v úložišti SteveSandersonMS/BlazorOnGitHubPagesGitHub:

• wwwroot/404.html
• Živý web

Při použití webu projektu místo webu organizace aktualizujte <base> značku v wwwroot/index.htmlsouboru . Nastavte hodnotu atributu href na název úložiště GitHubu pomocí koncového lomítka (například /my-repository/). V úložišti SteveSandersonMS/BlazorOnGitHubPagesGitHub se základ href aktualizuje při publikování konfiguračním .github/workflows/main.yml souborem.

Poznámka:

SteveSandersonMS/BlazorOnGitHubPages Úložiště GitHub není vlastněno, spravováno ani podporováno platformou .NET Foundation nebo Microsoftem.

Samostatná služba s Dockerem

Samostatná Blazor WebAssembly aplikace se publikuje jako sada statických souborů pro hostování statickým souborovým serverem.

Hostování aplikace v Dockeru:

• Vyberte kontejner Dockeru s podporou webového serveru, například Ngnix nebo Apache.
• publish Zkopírujte prostředky složky do složky umístění definované na webovém serveru pro obsluhu statických souborů.
• Podle potřeby použijte další konfiguraci pro obsluhu Blazor WebAssembly aplikace.

Pokyny ke konfiguraci najdete v následujících zdrojích informací:

• Oddíl Nginx nebo oddíl Apache tohoto článku
• Dokumentace k Dockeru

Hodnoty konfigurace hostitele

Blazor WebAssembly aplikace mohou přijmout následující hodnoty konfigurace hostitele jako argumenty příkazového řádku za běhu ve vývojovém prostředí.

Kořen obsahu

Argument --contentroot nastaví absolutní cestu k adresáři, který obsahuje soubory obsahu aplikace (kořen obsahu). V následujícíchpříkladch /content-root-path

• Předejte argument při místním spuštění aplikace na příkazovém řádku. V adresáři aplikace spusťte:

  dotnet watch --contentroot=/content-root-path
  

• Přidejte položku do souboru aplikace launchSettings.json v profilu SLUŽBY IIS Express . Toto nastavení se používá při spuštění aplikace pomocí ladicího programu sady Visual Studio a z příkazového řádku s dotnet watch (nebo dotnet run).

  "commandLineArgs": "--contentroot=/content-root-path"
  

• V sadě Visual Studio zadejte argument v argumentech>vlastností>. Nastavení argumentu na stránce vlastností sady Visual Studio přidá argument do launchSettings.json souboru.

  --contentroot=/content-root-path
  

Základ cesty

Argument --pathbase nastaví základní cestu aplikace pro aplikaci spuštěnou místně s jinou než kořenovou relativní cestou URL ( <base> značka href je nastavená na jinou cestu než / pro přípravu a produkční prostředí). V následujícíchpříkladch /relative-URL-path Další informace najdete v tématu Základní cesta aplikace.

Důležité

Na rozdíl od cesty poskytnuté značky href<base> při předávání / hodnoty argumentu nezahrnujte koncové lomítko (--pathbase). Pokud je základní cesta aplikace ve <base> značce zadaná jako <base href="/CoolApp/"> (obsahuje koncové lomítko), předejte hodnotu argumentu příkazového řádku jako --pathbase=/CoolApp (bez koncového lomítka).

• Předejte argument při místním spuštění aplikace na příkazovém řádku. V adresáři aplikace spusťte:

  dotnet watch --pathbase=/relative-URL-path
  

• Přidejte položku do souboru aplikace launchSettings.json v profilu SLUŽBY IIS Express . Toto nastavení se používá při spuštění aplikace pomocí ladicího programu sady Visual Studio a z příkazového řádku s dotnet watch (nebo dotnet run).

  "commandLineArgs": "--pathbase=/relative-URL-path"
  

• V sadě Visual Studio zadejte argument v argumentech>vlastností>. Nastavení argumentu na stránce vlastností sady Visual Studio přidá argument do launchSettings.json souboru.

  --pathbase=/relative-URL-path
  

Adresy URL

Argument --urls nastaví IP adresy nebo hostitelské adresy s porty a protokoly pro naslouchání požadavkům.

• Předejte argument při místním spuštění aplikace na příkazovém řádku. V adresáři aplikace spusťte:

  dotnet watch --urls=http://127.0.0.1:0
  

• Přidejte položku do souboru aplikace launchSettings.json v profilu SLUŽBY IIS Express . Toto nastavení se používá při spuštění aplikace pomocí ladicího programu sady Visual Studio a z příkazového řádku s dotnet watch (nebo dotnet run).

  "commandLineArgs": "--urls=http://127.0.0.1:0"
  

• V sadě Visual Studio zadejte argument v argumentech>vlastností>. Nastavení argumentu na stránce vlastností sady Visual Studio přidá argument do launchSettings.json souboru.

  --urls=http://127.0.0.1:0
  

Konfigurace ořezávání

Blazor provádí oříznutí zprostředkujícího jazyka (IL) na každém sestavení vydané verze, aby se z výstupních sestavení odebrala nepotřebná il. Další informace naleznete v tématu Konfigurace trimmeru pro ASP.NET Core Blazor.

Změna přípony názvu souboru DLL

Tato část platí pro ASP.NET Core 6.x a 7.x. V ASP.NET Core v .NET 8 nebo novějších se sestavení .NET nasazují jako soubory WebAssembly (.wasm) pomocí formátu souboru Webcil. V ASP.NET Core v .NET 8 nebo novějším platí tato část jenom v případě, že je ve formátu souboru projektu aplikace zakázaný formát souboru webcilu.

Pokud brána firewall, antivirový program nebo zařízení pro zabezpečení sítě blokuje přenos souborů knihovny DLL (Dynamic Link Library) aplikace (.dllDLL), můžete podle pokynů v této části změnit přípony názvů souborů publikované knihovny DLL aplikace.

Poznámka:

Změna přípon názvů souborů DLL aplikace nemusí tento problém vyřešit, protože mnoho systémů zabezpečení kontroluje obsah souborů aplikace, nikoli pouze kontrolovat přípony souborů.

Pro robustnější přístup v prostředích, která blokují stahování a spouštění souborů DLL, použijte ASP.NET Core v .NET 8 nebo novějším, který zabalí sestavení .NET jako soubory WebAssembly (.wasm) pomocí formátu souboru Webcil . Další informace naleznete ve formátu balení webového vzorníku pro sestavení .NET v části 8.0 nebo novější verze tohoto článku.

Pro řešení tohoto problému existují přístupy třetích stran. Další informace naleznete na webu Awesome Blazor.

Po publikování aplikace pomocí skriptu prostředí nebo kanálu buildu DevOps přejmenujte .dll soubory tak, aby používaly jinou příponu souboru v adresáři publikovaného výstupu aplikace.

V následujících příkladech:

• K aktualizaci přípon souborů se používá PowerShell (PS).
• .dll soubory se přejmenují tak, aby používaly příponu .bin souboru z příkazového řádku.
• Soubory uvedené v publikovaném blazor.boot.json souboru s příponou .dll souboru se aktualizují na příponu .bin souboru.
• Pokud se používají i prostředky pracovního procesu služby, příkaz PowerShellu aktualizuje .dll soubory uvedené v service-worker-assets.js souboru na příponu .bin souboru.

Chcete-li použít jinou příponu souboru než .bin, nahraďte .bin v následujících příkazech požadovanou příponou souboru.

Ve Windows:

dir {PATH} | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content {PATH}\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\blazor.boot.json

V předchozím příkazu {PATH} je zástupným symbolem cesta k publikované _framework složce (například .\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework z kořenové složky projektu).

Pokud se používají i prostředky pracovního procesu služby:

((Get-Content {PATH}\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\service-worker-assets.js

V předchozím příkazu {PATH} představuje zástupný symbol cestu k publikovanému service-worker-assets.js souboru.

V Linuxu nebo macOS:

for f in {PATH}/*; do mv "$f" "`echo $f | sed -e 's/\.dll/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' {PATH}/blazor.boot.json

V předchozím příkazu {PATH} je zástupným symbolem cesta k publikované _framework složce (například .\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework z kořenové složky projektu).

Pokud se používají i prostředky pracovního procesu služby:

sed -i 's/\.dll"/.bin"/g' {PATH}/service-worker-assets.js

V předchozím příkazu {PATH} představuje zástupný symbol cestu k publikovanému service-worker-assets.js souboru.

Pokud chcete řešit komprimované blazor.boot.json.gz soubory a blazor.boot.json.br soubory, použijte některý z následujících přístupů:

• Odeberte komprimované blazor.boot.json.gz soubory a blazor.boot.json.br soubory. Komprese je tímto přístupem zakázaná.
• Znovu zkomprimujte aktualizovaný blazor.boot.json soubor.

Předchozí pokyny pro komprimovaný blazor.boot.json soubor platí také v případě, že se používají prostředky pracovního procesu služby. Odstraňte nebo rekomprimujte service-worker-assets.js.br a service-worker-assets.js.gz. V opačném případě kontroly integrity souborů v prohlížeči selžou.

Následující příklad Windows pro .NET 6 používá skript PowerShellu umístěný v kořenovém adresáři projektu. Následující skript, který zakáže kompresi, je základem pro další úpravy, pokud chcete soubor znovu zkomprimovat blazor.boot.json .

ChangeDLLExtensions.ps1::

param([string]$filepath,[string]$tfm)
dir $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.br

Pokud se používají i prostředky pracovního procesu služby, přidejte následující příkazy:

((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.br

V souboru projektu se skript spustí po publikování aplikace pro Release konfiguraci:

<Target Name="ChangeDLLFileExtensions" AfterTargets="AfterPublish" Condition="'$(Configuration)'=='Release'">
  <Exec Command="powershell.exe -command &quot;&amp; { .\ChangeDLLExtensions.ps1 '$(SolutionDir)' '$(TargetFramework)'}&quot;" />
</Target>

Poznámka:

Při přejmenování a opožděné načítání stejných sestavení najdete pokyny v lazy načtení sestavení v ASP.NET Core Blazor WebAssembly.

Server aplikace obvykle vyžaduje konfiguraci statického prostředku pro obsluhu souborů s aktualizovaným rozšířením. Pro aplikaci hostované službou IIS přidejte položku mapy MIME (<mimeMap>) pro novou příponu souboru v oddílu statického obsahu (<staticContent>) ve vlastním web.config souboru. Následující příklad předpokládá, že přípona souboru je změněna z .dll :.bin

<staticContent>
  ...
  <mimeMap fileExtension=".bin" mimeType="application/octet-stream" />
  ...
</staticContent>

Pokud se komprese používá, uveďte aktualizaci komprimovaných souborů:

<mimeMap fileExtension=".bin.br" mimeType="application/octet-stream" />
<mimeMap fileExtension=".bin.gz" mimeType="application/octet-stream" />

Odeberte položku pro příponu .dll souboru:

- <mimeMap fileExtension=".dll" mimeType="application/octet-stream" />

Odeberte položky komprimovaných .dll souborů, pokud se používá komprese :

- <mimeMap fileExtension=".dll.br" mimeType="application/octet-stream" />
- <mimeMap fileExtension=".dll.gz" mimeType="application/octet-stream" />

Další informace o vlastních web.config souborech najdete v části Použití vlastního web.config oddílu.

Poškození předchozího nasazení

Obvykle při nasazení:

• Nahradí se jenom soubory, které se změnily, což obvykle vede k rychlejšímu nasazení.
• Existující soubory, které nejsou součástí nového nasazení, zůstanou na místě pro použití novým nasazením.

Ve výjimečných případech může přetrvání souborů z předchozího nasazení poškodit nové nasazení. Úplné odstranění existujícího nasazení (nebo místně publikované aplikace před nasazením) může vyřešit problém s poškozeným nasazením. K vyřešení problému, včetně buildu DevOps a kanálu nasazení, často stačí odstranit stávající nasazení.

Pokud zjistíte, že vymazání předchozího nasazení se vždy vyžaduje, když se používá kanál buildu a nasazení DevOps, můžete dočasně přidat do kanálu buildu krok, který odstraní předchozí nasazení pro každé nové nasazení, dokud neodstraníte přesnou příčinu poškození.

Řešení chyb kontroly integrity

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, které nejsou uloženy v mezipaměti klientů. 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.

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

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 SHA256MD5:

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.

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