Share via

Runtime de ASP.NET Core Blazor WebAssembly .NET y almacenamiento en caché del lote de aplicaciones

  • Artículo

Nota:

Esta no es la versión más reciente de este artículo. Para la versión actual, consulte la versión .NET 8 de este artículo.

Importante

Esta información hace referencia a un producto en versión preliminar, el cual puede sufrir importantes modificaciones antes de que se publique la versión comercial. Microsoft no proporciona ninguna garantía, expresa o implícita, con respecto a la información proporcionada aquí.

Para la versión actual, consulte la versión .NET 8 de este artículo.

Cuando una aplicación Blazor WebAssembly se carga en el explorador, la aplicación descarga los recursos de arranque desde el servidor:

  • Código JavaScript para arrancar la aplicación
  • Runtime y ensamblados de .NET
  • Datos específicos de la configuración regional

A excepción del archivo de recursos de arranque de Blazor (blazor.boot.json), los archivos de runtime de WebAssembly .NET y de lote de aplicaciones se almacenan en caché en los clientes. El archivo blazor.boot.json contiene un manifiesto de los archivos que componen la aplicación que se debe descargar junto con un hash del contenido del archivo que se usa para detectar si alguno de los recursos de arranque ha cambiado. Blazor almacena en caché los archivos descargados mediante la API de Caché del explorador.

Cuando Blazor WebAssembly descarga los archivos de inicio de una aplicación, le indica al navegador que realice comprobaciones de integridad en las respuestas. Blazor envía valores hash SHA-256 para DLL (.dll), WebAssembly (.wasm) y otros archivos del archivo blazor.boot.json. Los códigos hash de los archivos almacenados en caché se comparan con los del archivo blazor.boot.json. Para los archivos almacenados en caché con un hash correspondiente, Blazor usa los archivos almacenados en caché. De lo contrario, los archivos se solicitan desde el servidor. Después de descargar un archivo, su hash se comprueba de nuevo para la validación de integridad. El explorador genera un error si se produce un error en la comprobación de integridad de cualquier archivo descargado.

Algoritmo de Blazor para administrar la integridad de los archivos:

  • Garantiza que la aplicación no corre el riesgo de cargar un conjunto de archivos incoherentes, por ejemplo, si se aplica una nueva implementación al servidor web mientras el usuario se encuentra en el proceso de descarga de los archivos de aplicación. Los archivos incoherentes pueden dar lugar a un funcionamiento incorrecto de la aplicación.
  • Garantiza que el explorador del usuario nunca almacene en caché respuestas incoherentes o no válidas, lo que puede impedir que se inicie la aplicación aunque el usuario actualice manualmente la página.
  • Hace que sea seguro almacenar en caché las respuestas y no comprobar los cambios en el lado servidor hasta que cambien los códigos hash SHA-256 esperados, por lo que las cargas de páginas posteriores implican menos solicitudes y se completan mucho más rápido.

Si el servidor web devuelve respuestas que no coinciden con los códigos hash SHA-256 esperados, verá un error similar al del ejemplo siguiente en la consola para desarrolladores del explorador:

No se ha podido encontrar ninguna síntesis válida en el atributo "integrity" del recurso "https://myapp.example.com/_framework/MyBlazorApp.dll" con la integridad de SHA-256 calculada "IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY=". El recurso se ha bloqueado.

En la mayoría de los casos, la advertencia no indica un problema con la comprobación de integridad. En su lugar, la advertencia normalmente significa que existe otro problema.

Nota:

Los vínculos de la documentación al origen de referencia de .NET cargan normalmente la rama predeterminada del repositorio, que representa el desarrollo actual para la próxima versión de .NET. Para seleccionar una etiqueta de una versión específica, use la lista desplegable Cambiar ramas o etiquetas. Para obtener más información, vea Procedimientos para seleccionar una etiqueta de versión de código fuente de ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Diagnóstico de problemas de integridad

Cuando se compila una aplicación, el manifiesto de blazor.boot.json generado describe los códigos hash SHA-256 de los recursos de arranque en el momento en que se ha generado la salida de la compilación. La comprobación de integridad se supera siempre que los algoritmos hash SHA-256 de blazor.boot.json coincidan con los archivos entregados al explorador.

Los motivos comunes por los que se produce un error incluyen:

  • La respuesta del servidor web es un error (por ejemplo, 404 No encontrado o 500 Error interno del servidor) en lugar del archivo solicitado por el explorador. El explorador lo detecta como un error de comprobación de integridad y no como un error de respuesta.
  • Algo ha cambiado el contenido de los archivos entre la compilación y la entrega de los archivos al explorador. Esto puede ocurrir:
    • Si el usuario o las herramientas de compilación modifican manualmente la salida de compilación.
    • Si algún aspecto del proceso de implementación ha modificado los archivos. Por ejemplo, si usa un mecanismo de implementación basado en Git, tenga en cuenta que Git convierte de forma transparente los finales de línea de estilo Windows en finales de línea de estilo Unix si confirma archivos en Windows y los comprueba en Linux. El cambio de los finales de línea de archivo cambia los algoritmos hash SHA-256. Para evitar este problema, considere la posibilidad de usar .gitattributes para tratar los artefactos de compilación como archivos binary.
    • El servidor web modifica el contenido del archivo como parte del servicio. Por ejemplo, algunas redes de distribución de contenido (CDN) intentan automáticamente minimizar HTML, con lo que se modifica. Es posible que tenga que deshabilitar estas características.
  • El archivo blazor.boot.json no se carga correctamente o se almacena en caché incorrectamente en el cliente. Entre las causas comunes se incluye una de las siguientes:
    • Código de desarrollador personalizado mal configurado o que no funciona correctamente.
    • Una o varias capas de almacenamiento en caché intermedias mal configuradas.

Para diagnosticar cuál de ellas se aplica en su caso:

  1. Lea el mensaje de error para darse cuenta de qué archivo está desencadenando el error.
  2. Abra las herramientas de desarrollo del explorador y mire en la pestaña Red. Si es necesario, vuelva a cargar la página para ver la lista de solicitudes y respuestas. Busque el archivo que desencadena el error en esa lista.
  3. Compruebe el código de estado HTTP en la respuesta. Si el servidor devuelve un valor distinto de 200 - Correcto (u otro código de estado 2XX), tiene un problema de servidor por diagnosticar. Por ejemplo, el código de estado 403 significa que hay un problema de autorización, mientras que el código de estado 500 significa que el servidor está dando error de una manera no especificada. Consulte los registros del servidor para diagnosticar y corregir la aplicación.
  4. Si el código de estado es 200 - Correcto para el recurso, examine el contenido de la respuesta en las herramientas de desarrollo del explorador y compruebe que el contenido coincida con los datos esperados. Por ejemplo, un problema común es configurar erróneamente el enrutamiento de modo que las solicitudes devuelvan los datos de index.html incluso para otros archivos. Asegúrese de que las respuestas a las solicitudes de .wasm son archivos binarios de WebAssembly y que las respuestas a las solicitudes de .dll son archivos binarios de ensamblado de .NET. Si no es así, tiene un problema de enrutamiento del lado servidor por diagnosticar.
  5. Trate de validar la salida publicada e implementada de la aplicación con el script de PowerShell para solucionar problemas de integridad.

Si confirma que el servidor está devolviendo datos plausiblemente correctos, debe haber algo más que modifique el contenido entre la compilación y la entrega del archivo. Para investigarlo:

  • Examine la cadena de herramientas de compilación y el mecanismo de implementación en caso de que estén modificando archivos después de compilarlos. Un ejemplo de esto es cuando GIT transforma los finales de línea de los archivos, tal y como se ha descrito anteriormente.
  • Examine el servidor web o la configuración de CDN en caso de que estén configurados para modificar las respuestas de forma dinámica (por ejemplo, intentando minimizar HTML). Está adecuado que el servidor web implemente la compresión HTTP (por ejemplo, devolviendo content-encoding: br o content-encoding: gzip), ya que esto no afecta al resultado después de la descompresión. Sin embargo, no es adecuado que el servidor web modifique los datos sin comprimir.

Script de PowerShell para solucionar problemas de integridad

Use el script integrity.ps1 de PowerShell para validar una aplicación Blazor publicada e implementada. El script se proporciona para PowerShell Core 7 o posterior como punto inicial cuando la aplicación tiene problemas de integridad que el marco Blazor no puede identificar. La personalización del script puede ser necesaria para las aplicaciones, incluso si se ejecuta en una versión de PowerShell posterior a la versión 7.2.0.

El script revisa los archivos de la carpeta publish y los descarga de la aplicación implementada para detectar problemas en los distintos manifiestos que contienen valores hash de integridad. Estas comprobaciones deben detectar los problemas más comunes:

  • Modificó un archivo en la salida publicada sin darse cuenta.
  • La aplicación no se implementó correctamente en el destino de la implementación o hubo algún cambio en el entorno del destino de la implementación.
  • Hay diferencias entre la aplicación implementada y la salida de la publicación de la aplicación.

Use el comando siguiente en un shell de comandos de PowerShell para invocar el script:

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

En el ejemplo siguiente, el script se ejecuta en una aplicación que se ejecuta localmente en https://localhost:5001/:

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

Marcadores de posición:

  • {BASE URL}: la dirección URL de la aplicación implementada. Se requiere la barra diagonal (/).
  • {PUBLISH OUTPUT FOLDER}: la ruta de acceso a la carpeta publish de la aplicación o a la ubicación donde se publica la aplicación para la implementación.

Nota

Al clonar el repositorio de GitHub dotnet/AspNetCore.Docs, Bitdefender o cualquier otro antivirus del sistema podrían poner en cuarentena el script integrity.ps1. Normalmente, la tecnología de detección heurística de un antivirus intercepta el archivo, buscando simplemente patrones en archivos que podrían indicar la presencia de malware. Para evitar que el antivirus ponga el archivo en cuarentena, agregue una excepción al antivirus antes de clonar el repositorio. El ejemplo siguiente es una ruta de acceso típica al script en un sistema Windows. Ajuste la ruta de acceso según sea necesario para otros sistemas. El marcador de posición {USER} es el segmento de la ruta de acceso del usuario.

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

Advertencia: La creación de excepciones para el antivirus es peligrosa y solo se debe realizar cuando tenga la certeza de que el archivo es seguro.

Comparar la suma de comprobación de un archivo con un valor de suma de comprobación válido no garantiza la seguridad de los archivos, pero modificar un archivo de forma que mantenga un valor de suma de comprobación no es trivial para los usuarios malintencionados. Por lo tanto, las sumas de comprobación son útiles como enfoque de seguridad general. Compare la suma de comprobación del archivo local integrity.ps1 con uno de los valores siguientes:

  • SHA256: 32c24cb667d79a701135cb72f6bae490d81703323f61b8af2c7e5e5dc0f0c2bb
  • MD5: 9cee7d7ec86ee809a329b5406fbf21a8

Obtenga la suma de comprobación del archivo en el sistema operativo Windows con el siguiente comando. Proporcione la ruta de acceso y el nombre de archivo para el marcador de posición {PATH AND FILE NAME} e indique el tipo de suma de comprobación que se debe generar para el marcador de posición {SHA512|MD5}, bien SHA256 o MD5:

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

Si tiene algún motivo para preocuparse de que la validación de la suma de comprobación no sea lo suficientemente segura en su entorno, consúltelo con el responsable de seguridad de su organización para obtener instrucciones.

Para obtener más información, consulte Información general sobre la protección contra amenazas del antivirus Microsoft Defender.

Deshabilitación de las comprobaciones de integridad y almacenamiento en caché de recursos para aplicaciones que no son PWA

En la mayoría de los casos, no deshabilite la comprobación de integridad. Al deshabilitar la comprobación de integridad, no se soluciona el problema subyacente que ha causado las respuestas inesperadas y se pierden las ventajas mencionadas anteriormente.

Puede haber casos en los que no se pueda confiar en el servidor web para que devuelva respuestas coherentes, y solo le queda la opción de deshabilitar temporalmente las comprobaciones de integridad hasta que se resuelva el problema subyacente.

Para deshabilitar las comprobaciones de integridad, agregue lo siguiente a un grupo de propiedades en el archivo del proyecto de la aplicación Blazor WebAssembly (.csproj):

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResources también deshabilita el comportamiento predeterminado de Blazorde almacenar en caché .dll, .wasm y otros archivos según sus algoritmos hash SHA-256, ya que la propiedad indica que no se puede confiar en la exactitud de los algoritmos hash SHA-256. Incluso con esta configuración, es posible que la memoria caché HTTP normal del explorador siga almacenando en caché esos archivos, pero que esto suceda o no depende de la configuración del servidor web y de los encabezados de cache-control a los que sirve.

Nota

La propiedad BlazorCacheBootResources no deshabilita las comprobaciones de integridad de las aplicaciones web progresivas (PWA). Para obtener instrucciones relativas a las PWA, consulte la sección Deshabilitación de la comprobación de integridad para aplicaciones PWA.

No se puede proporcionar una lista exhaustiva de escenarios en los que es necesario deshabilitar la comprobación de integridad. Los servidores pueden responder a una solicitud de maneras arbitrarias fuera del ámbito del marco Blazor. El marco proporciona el valor BlazorCacheBootResources para que la aplicación se pueda ejecutar a costa de perder una garantía de integridad que la aplicación puede proporcionar. Una vez más, no se recomienda deshabilitar la comprobación de integridad, especialmente para las implementaciones de producción. Los desarrolladores deben intentar resolver el problema de integridad subyacente que provoca un error en la comprobación de la integridad.

Algunos casos generales que pueden causar problemas de integridad son los siguientes:

  • Se ejecuta en HTTP, donde no se puede comprobar la integridad.
  • Si el proceso de implementación modifica los archivos después de la publicación de alguna manera.
  • Si el host modifica los archivos de alguna manera.

Deshabilitación del almacenamiento en caché de recursos y comprobaciones de integridad de PWA

La plantilla de aplicación web progresiva (PWA) de Blazor contiene un archivo service-worker.published.js sugerido que es responsable de capturar y almacenar archivos de la aplicación para su uso sin conexión. Se trata de un proceso independiente del mecanismo de inicio de la aplicación normal y tiene su propia lógica de comprobación de integridad independiente.

Dentro del archivo service-worker.published.js, está presente la línea siguiente:

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

Para deshabilitar la comprobación de la integridad, quite el parámetro integrity cambiando la línea por lo siguiente:

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

De nuevo, deshabilitar la comprobación de la integridad significa que se pierden las garantías de seguridad que ofrece este servicio. Por ejemplo, existe el riesgo de que si el explorador del usuario almacena en caché la aplicación en el momento exacto en que implementa una nueva versión, podría almacenar en caché algunos archivos de la implementación anterior y otros de la implementación nueva. Si eso sucede, la aplicación se bloquea en un estado interrumpido hasta que implemente una actualización adicional.

Recursos adicionales

Carga de recursos de arranque