Closed secana closed 4 years ago
Any update on this? I'm afraid to upgrade our project to RC right now.
Thanks for contacting us, @secana. We have investigated this a bit and we need a repro on how did you get into this state? Also, what does your deployment look like?
Hi @mkArtakMSFT my deployment is pretty simple Azure DevOps pipeline, which pushes the build artifacts to an Azure Storage instance.
# Build and deploy pipeline for PeNet Web
trigger:
branches:
include:
- '*'
tags:
include:
- '*'
pool:
vmImage: 'windows-latest'
variables:
buildConfiguration: 'Release'
steps:
- task: UseDotNet@2
displayName: 'Use latest .NET SDK 3.x'
inputs:
packageType: sdk
version: 3.x
includePreviewVersions: true
- powershell: ((Get-Content -path ".\PeNet Web\PeNet Web.csproj" -Raw) -replace '<ServiceWorkerCacheVersion>1</ServiceWorkerCacheVersion>','<ServiceWorkerCacheVersion>$(Build.BuildId)</ServiceWorkerCacheVersion>') | Set-Content -Path ".\PeNet Web\PeNet Web.csproj"
displayName: Replace cache version with build ID
- powershell: 'dotnet publish -c Release'
displayName: 'Build app'
- task: AzureFileCopy@3
displayName: 'Upload to Azure storage'
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
inputs:
sourcePath: '$(System.DefaultWorkingDirectory)\PeNet Web\bin\Release\netstandard2.1\publish\wwwroot'
azureSubscription: 'Azure penetWeb'
Destination: 'AzureBlob'
storage: 'storagepenetweb'
ContainerName: '$web'
cleanTargetBeforeCopy: true
- task: PurgeAzureCDNEndpoint@2
displayName: Purge CDN Cache
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
inputs:
ConnectedServiceNameARM: 'Azure penetWeb'
ConnectedServiceNameSelector: 'ConnectedServiceNameARM'
ResourceGroupName: 'penetWeb'
EndpointName: 'penet'
ProfileName: 'penetCdn'
The projects itself compiles and runs fine on my local machine, but breaks with the mentioned error above every time it is deployed to Azure.
Is there any specific information that you need that I can provide?
We are hosting the app with Nginx and Kestrel. Locally works perfect but the error occurs when published. Microsoft.AspNetCore.Components.WebAssembly 3.2.0-rc1.20223.4
Failed to find a valid digest in the 'integrity' attribute for resource 'https://sdc.kite.net.ar/chat-helper.js' with computed SHA-256 integrity 'LfY6L5UG4jcFbYlFvPHHY6eMyY40U8E9OBXzDuzLM4Q='. The resource has been blocked. Unknown error occurred while trying to verify integrity. service-worker.js:1 Uncaught (in promise) TypeError: Failed to fetch Failed to find a valid digest in the 'integrity' attribute for resource 'https://sdc.kite.net.ar/css/app.css' with computed SHA-256 integrity 'CLMwCdXSHqGZJPkmVzrW5AzX0GqL2ZMFG0ZMmKJhCxs='. The resource has been blocked. Unknown error occurred while trying to verify integrity. Failed to find a valid digest in the 'integrity' attribute for resource 'https://sdc.kite.net.ar/favicon.ico' with computed SHA-256 integrity 'W5EPg2n8bPBFA8JHSN5nzjiwHZWsygLHMOR6vKQibnY='. The resource has been blocked. Unknown error occurred while trying to verify integrity. Failed to find a valid digest in the 'integrity' attribute for resource 'https://sdc.kite.net.ar/index.html' with computed SHA-256 integrity '+AbrlijS9zWZHwrFn/hGdZXkrX7NzvMPs6KG9RtBPXk='. The resource has been blocked. Unknown error occurred while trying to verify integrity. Failed to find a valid digest in the 'integrity' attribute for resource 'https://sdc.kite.net.ar/css/bootstrap/bootstrap.min.css' with computed SHA-256 integrity 'YLGeXaapI0/5IgZopewRJcFXomhRMlYYjugPLSyNjTY='. The resource has been blocked. Unknown error occurred while trying to verify integrity.
Is this related to #19796
@MortenMeisler I tried the provided solutions from #19796 with no success. What I did:
autocrlf=false
* binary
This did not fix the broken integrity check.
Additionally I set the <BlazorCacheBootResources>false</BlazorCacheBootResources>
flag, which resulted in another Blazor related error.
@MortenMeisler we doens't used Git, in this case, but our scenario is number 2 (build machine is Windows and production server is Linux). We also tried <BlazorCacheBootResources>false</BlazorCacheBootResources>
without positive result.
@secana Sounds like the Git config might not be correct:
.gitattributes
, not .gitignore
.gitattributes
, you must run something like git add --renormalize .
to make it take effect. You should see the affected files show up as modified and needing to be committed into your Git repo. If the files don't show up as modified, then your config change hasn't taken effect.With the new (not preview) release the problem disappeared in my app. Not sure if the problems is solved for the others here, too.
For me it seems to be solved aswell.
I updated to the latest version of Blazor but the problem persist. My issue is related to the integrity check of static files, like ico, css, js, html. The build machine is Windows and the server is Linux (Nginx + Kestrel).
You can check it going to https://sdc.kite.net.ar/
Failed to find a valid digest in the 'integrity' attribute for resource 'https://sdc.kite.net.ar/chat-helper.js' with computed SHA-256 integrity 'LfY6L5UG4jcFbYlFvPHHY6eMyY40U8E9OBXzDuzLM4Q='. The resource has been blocked. Unknown error occurred while trying to verify integrity. service-worker.js:1 Uncaught (in promise) TypeError: Failed to fetch Failed to find a valid digest in the 'integrity' attribute for resource 'https://sdc.kite.net.ar/css/app.css' with computed SHA-256 integrity 'CLMwCdXSHqGZJPkmVzrW5AzX0GqL2ZMFG0ZMmKJhCxs='. The resource has been blocked. Unknown error occurred while trying to verify integrity. Failed to find a valid digest in the 'integrity' attribute for resource 'https://sdc.kite.net.ar/css/bootstrap/bootstrap.min.css' with computed SHA-256 integrity 'YLGeXaapI0/5IgZopewRJcFXomhRMlYYjugPLSyNjTY='. The resource has been blocked. Unknown error occurred while trying to verify integrity. Failed to find a valid digest in the 'integrity' attribute for resource 'https://sdc.kite.net.ar/favicon.ico' with computed SHA-256 integrity 'W5EPg2n8bPBFA8JHSN5nzjiwHZWsygLHMOR6vKQibnY='. The resource has been blocked. Unknown error occurred while trying to verify integrity. Failed to find a valid digest in the 'integrity' attribute for resource 'https://sdc.kite.net.ar/index.html' with computed SHA-256 integrity '+AbrlijS9zWZHwrFn/hGdZXkrX7NzvMPs6KG9RtBPXk='. The resource has been blocked. Unknown error occurred while trying to verify integrity.
I was having this issue without Azure being involved. Just upgraded a standard project and suddenly integrity was broken with all DLLs.
I had same problem on Azure CDN. My problem was caching though. Have you checked your cachings?
Hi,
We have the same issue (see screenshot for some of them), i.e. when using our on premise (not cloud based) Azure DevOps Server pipelines. The integrity issue is only with the DLLs.
A Visual Studio publish is fine on my local machine (although we did not test the access from another machine). Also accessing "locally" from the server to which we have deployed (using the pipelines) is fine. I even tried to use the same options when doing the publish from VS, i.e. "runtime Portable" which seemed to be the only big difference.
Here's the YAML for the build pipeline. We use the template "IIS website deployment" for the release pipeline.
pool:
name: Default
demands: Cmd
steps:
- task: NuGetToolInstaller@1
displayName: 'Use NuGet '
inputs:
checkLatest: true
- task: NuGetCommand@2
displayName: 'NuGet restore'
inputs:
restoreSolution: FichePompageUI/FichePompageUI.sln
feedsToUse: config
nugetConfigPath: FichePompageUI/NuGet.Config
- task: BatchScript@1
displayName: 'Rename pipelineRelease_Web.config to Web.config'
inputs:
filename: 'FichePompageUI\renameConfig.cmd'
- task: DotNetCoreCLI@2
displayName: 'dotnet publish Release'
inputs:
command: publish
arguments: '--configuration Release --runtime Portable'
- task: CopyFiles@2
displayName: 'Copy publish.zip to $(Build.ArtifactStagingDirectory)'
inputs:
SourceFolder: '$(System.DefaultWorkingDirectory)'
Contents: |
**\publish.zip
TargetFolder: '$(Build.ArtifactStagingDirectory)'
CleanTargetFolder: true
flattenFolders: true
- task: PublishBuildArtifacts@1
displayName: 'Publish Artifact: FichePompageUIDrop'
inputs:
ArtifactName: FichePompageUIDrop
Thanks
I am not sure if anyone is still following this issue.
In that case should I create a new one?
Have you tried @SteveSandersonMS suggestions from this issue: #19796 or as per comment above https://github.com/dotnet/aspnetcore/issues/21383#issuecomment-627904962 ?
Hi,
I tried the suggestion (although I consider this one as a weird one) regarding the .gitattributes in the _framework folder. Unfortunately I get the following compilation errors.
Error Could not copy the file "C:\Users\sroy\source\repos\BitumarGit\FichePompage\FichePompageUI\obj\Release\netstandard2.1\compressed\_framework\.gitattributes.gz" because it was not found. FichePompageUI 0
Error Could not copy the file "C:\Users\sroy\source\repos\BitumarGit\FichePompage\FichePompageUI\obj\Release\netstandard2.1\compressed\_framework\.gitattributes.br" because it was not found. FichePompageUI 0
FYI, I tried to access from another machine a deployment done with a Visual Studio publish (where the DLLs are never under Git control) and the issue is the same.
I'm pretty sure someone found the root cause for this but unfortunately I did not find the Web page yet ;)
Thanks
@sroy2020 It looks like maybe you put your .gitattributes
file in an incorrect place, though it's hard to be sure. In any case, the .gitattributes
config will only affect text files, not binary ones like .dll
s.
As a bigger workaround, consider adding <BlazorCacheBootResources>false</BlazorCacheBootResources>
into a propertygroup in your client project's .csproj
. This will disable caching and integrity checking.
@sroy2020 Actually if you look closely at your screenshot above, you can see the server is responding 403 Forbidden. That's the real issue here, nothing to do with .gitattributes
or integrity. You'll have to sort out your hosting server to actually return the files and not give these 403 responses.
Hi,
Oh boy! I completely overlooked the 403... Thanks a lot for pointing that out, this seems to be the real issue, the integrity one might just be a side-effect.
I'll look at this.
Again thanks a lot!
Hi,
After investigation we have found the root cause. Our IT dept has set up special rules in the anti-virus. It's blocking all DLL downloads.
See New Blazor WebAssembly 3.2, Dll files are blocking by the antivirus sophos
Thanks
@secana I tried publishing a Blazor WebAssembly PWA (directly from the 3.2.0 project template) to Azure blob storage using the same AzDO pipeline steps as you've shown above, and it worked absolutely fine.
I also enabled Azure CDN for the static site, and that worked too.
So it seems like there is some other problem affecting your deployment. I'd suggest checking the Network tab in your browser to see if the server is returning failure status codes for any of the requests. For example, if it's serving 404 or 401 responses for any of the content, that would cause an integrity violation error.
@SteveSandersonMS with 3.2.0 it works. Just breaks for the preview version, so for me the it's fixed. But it seems other still have problems. Thx for being so responsive!
Thanks. Closing as answered then.
If others do have problems:
.js
/.html
/.dll
/.wasm
/etc are actually returning the status code 200. If that's not the case, your real problem is with the hosting server.Note that if you see integrity check failures only on text-type files (.html
/.css
/.js
) but not on binary-type files (.dll
/.wasm
), and your deployment mechanism involves Git in some way, then it's likely to be Git's Auto-CRLF handling that is modifying your files, in which case look at using the .gitattributes
solution described above.
Describe the bug
Blazor WebAssembly 3.2.0 breaks the integrity of published modules.
To Reproduce
Upgraded a project to the Blazor RC and published it to Azure. No code was changed. The project runs fine locally but does not load from Azure.
Browser shows the following error messages. Seems that the integrity of some dlls cannot be verified. I rebuild multiple times, always with the same effect.
I'm not sure if this is an Blazor RC problem or an Azure hosting problem, but as the only thing I changed is the Blazor version and everything else is the same, I assume something went from with the RC.