Falhas de cache e verificação de integridade do pacote ASP.NET Core Blazor WebAssembly .NET

Este artigo explica o armazenamento em cache de ativos para Blazor WebAssembly e como identificar e resolver problemas de integridade.

Quando um Blazor WebAssembly aplicativo é carregado no navegador, o aplicativo baixa recursos de inicialização do servidor:

• Código JavaScript para inicializar o aplicativo
• Tempo de execução e assemblies do .NET
• Dados específicos da localidade

Blazoralgoritmo para gerir a integridade do ficheiro:

• Garante que o aplicativo não corra o risco de carregar um conjunto inconsistente de arquivos, por exemplo, se uma nova implantação for aplicada ao seu servidor Web enquanto o usuário estiver no processo de download dos arquivos do aplicativo. Arquivos inconsistentes podem resultar em um aplicativo com defeito.
• Garante que o navegador do usuário nunca armazene em cache respostas inconsistentes ou inválidas, o que pode impedir que o aplicativo seja iniciado, mesmo que o usuário atualize manualmente a página.
• Torna seguro armazenar em cache as respostas e não verificar se há alterações no servidor até que os próprios hashes SHA-256 esperados mudem, para que os carregamentos de página subsequentes envolvam menos solicitações e sejam concluídos mais rapidamente.

Se o servidor Web retornar respostas que não correspondem aos hashes SHA-256 esperados, um erro semelhante ao exemplo a seguir será exibido no console do desenvolvedor do navegador:

Não foi possível encontrar um resumo válido no atributo 'integridade' para o recurso 'https://myapp.example.com/_framework/MyBlazorApp.dll' com integridade SHA-256 computada 'IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY='. O recurso foi bloqueado.

Na maioria dos casos, o aviso não indica um problema com a verificação de integridade. Em vez disso, o aviso geralmente significa que existe algum outro problema.

Para obter a fonte de referência de inicialização do Blazor WebAssembly, consulte o arquivo Boot.WebAssembly.ts no repositório dotnet/aspnetcore GitHub.

Diagnosticar problemas de integridade

Quando um aplicativo é criado, o manifesto de inicialização gerado descreve os hashes SHA-256 de recursos de inicialização no momento em que a saída de compilação é produzida. A verificação de integridade passa desde que os hashes SHA-256 no manifesto de inicialização correspondam aos arquivos entregues ao navegador.

As razões comuns pelas quais isso não acontece incluem:

• A resposta do servidor Web é um erro (por exemplo, um 404 - Not Found ou um 500 - Internal Server Error) em vez do ficheiro que o navegador solicitou. Isso é relatado pelo navegador como uma falha de verificação de integridade e não como uma falha de resposta.
• Algo mudou o conteúdo dos arquivos entre a compilação e a entrega dos arquivos para o navegador. Isto pode acontecer:
  • Se você ou as ferramentas de compilação modificarem manualmente a saída da compilação.
  • Se algum aspeto do processo de implantação modificou os arquivos. Por exemplo, se utilizares um mecanismo de implantação baseado em Git, tem em conta que o Git converte de forma transparente terminações de linha no estilo Windows para terminações de linha no estilo Unix se confirmares ficheiros no Windows e os extraires no Linux. A alteração das terminações das linhas de arquivo altera os hashes SHA-256. Para evitar esse problema, considere usando .gitattributes para tratar artefatos de compilação como arquivos binary.
  • O servidor web modifica o conteúdo do ficheiro durante o processo de entrega. Por exemplo, algumas redes de distribuição de conteúdo (CDNs) tentam automaticamente minificar HTML, modificando-o. Pode ser necessário desativar esses recursos.
• O manifesto de inicialização não é carregado corretamente ou é armazenado incorretamente em cache no cliente. As causas comuns incluem uma das seguintes:
  • Código de desenvolvedor personalizado mal configurado ou com mau funcionamento.
  • Uma ou mais camadas de cache intermediárias mal configuradas.

Para diagnosticar qual delas se aplica no seu caso:

Se você confirmar que o servidor está retornando dados plausivelmente corretos, deve haver algo mais modificando o conteúdo entre a compilação e a entrega do arquivo. Para investigar isso:

• Examine a cadeia de ferramentas de compilação e o mecanismo de implantação caso eles estejam modificando arquivos depois que os arquivos forem criados. Um exemplo disso é quando o Git transforma terminações de linha de arquivo, conforme descrito anteriormente.
• Examine a configuração do servidor Web ou da CDN caso eles estejam configurados para modificar respostas dinamicamente (por exemplo, tentando reduzir o HTML). Não há problema em o servidor Web implementar a compactação HTTP (por exemplo, retornar content-encoding: br ou content-encoding: gzip), já que isso não afeta o resultado após a descompressão. No entanto, não é aceitável que o servidor web modifique os dados não compactados.

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

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

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

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

Desativar a verificação de integridade para aplicativos que não sejam PWA

Na maioria dos casos, não desative a verificação de integridade. Desativar a verificação de integridade não resolve o problema subjacente que causou as respostas inesperadas e resulta na perda dos benefícios listados anteriormente.

Pode haver casos em que o servidor Web não possa ser confiável para retornar respostas consistentes, e você não tem escolha a não ser desativar temporariamente as verificações de integridade até que o problema subjacente seja resolvido.

<BlazorCacheBootResources>false</BlazorCacheBootResources>

Não podemos fornecer uma lista exaustiva de cenários em que a desativação da verificação de integridade é necessária. Os servidores podem responder a uma solicitação de maneiras arbitrárias fora do escopo da estrutura Blazor. A estrutura permite que a abordagem anterior torne o aplicativo executável ao custo de perder uma garantia de integridade que o aplicativo pode fornecer. Mais uma vez, não recomendamos desativar a verificação de integridade, especialmente para implantações de produção. Os desenvolvedores devem procurar resolver o problema de integridade subjacente que está causando falha na verificação de integridade.

Alguns casos gerais que podem causar problemas de integridade são:

• Em execução em HTTP onde a integridade não pode ser verificada.
• Se o seu processo de implantação modifica os arquivos após a publicação de qualquer forma.
• Se o seu anfitrião modificar os ficheiros de alguma forma.

Desativar a verificação de integridade para PWAs

O modelo de Aplicação Web Progressiva (PWA) do Blazorcontém um arquivo service-worker.published.js sugerido que é responsável por buscar e armazenar ficheiros da aplicação para uso offline. Este é um processo separado do mecanismo normal de inicialização do aplicativo e tem sua própria lógica de verificação de integridade separada.

Dentro do arquivo service-worker.published.js, a seguinte linha está presente:

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

Para desativar a verificação de integridade, remova o parâmetro integrity alterando a linha para o seguinte:

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

Mais uma vez, desativar a verificação de integridade significa que você perde as garantias de segurança oferecidas pela verificação de integridade. Por exemplo, há um risco de que, se o navegador do usuário estiver armazenando o aplicativo em cache no momento exato em que você implanta uma nova versão, ele poderá armazenar em cache alguns arquivos da implantação antiga e alguns da nova implantação. Se isso acontecer, o aplicativo ficará preso em um estado quebrado até que você implante uma nova atualização.