Autumn
Autumn

Reputation: 866

wasm/dotnet Integrity attribute invalid for my Blazor app on Github pages

See the error on my website here

I have embedded a blazor app in my jekyll site. It runs perfectly locally, but when I publish it on github pages, I am getting this error:

Failed to find a valid digest in the 'integrity' attribute for resource 'https://chrisevans9629.github.io/blazor/xt/_framework/wasm/dotnet.3.2.0-rc1.20222.2.js' with computed SHA-256 integrity 'yVt8FYsTQDifOGsifIkmEXwe+7ML0jZ1dMi2xluiDXQ='. The resource has been blocked.

This is something that I think blazor generates when the page is ran. this is what my page looks like that starts blazor:

<script src="js/index.js"></script>
<app>Loading...</app>
Built with <3 using Blazor
<script src="_framework/blazor.webassembly.js"></script>

This is what the page looks like on github pages:


<script src="js/index.js"></script>

<app>Loading...</app>
<p>Built with &lt;3 using Blazor
<script src="_framework/blazor.webassembly.js"></script></p>        

<script type="text/javascript">var Module; window.__wasmmodulecallback__(); delete window.__wasmmodulecallback__;</script><script src="_framework/wasm/dotnet.3.2.0-rc1.20222.2.js" defer="" integrity="sha256-iZCHkFXJWYNxCUFwhj+4oqR4fkEJc5YGjfTTvdIuX84=" crossorigin="anonymous"></script></body>

Why is this error happening and how can I fix this? I've thought about create a script that would remove the integrity attribute, but I don't think that would be a good solution.

Upvotes: 14

Views: 10753

Answers (10)

pauldendulk
pauldendulk

Reputation: 1598

I resolved this problem by upgrading to .NET 8. I used deployment through github pages which might have been part of the problem.

Upvotes: 0

JG222
JG222

Reputation: 188

I Had this same issue and none of these solutions worked for me, but they set me on the right path. I am deploying mine to my local machine and using IIS for testing purposes, and I found that in the publish profile that I have created in Visual Studio 2022, the check box to "Remove additional files at destination" was not checked and as soon as I checked this and republished it, everything worked fine. I must have removed a file that was being published in a previous build and it was still there since it wasn't being deleted by any subsequent builds/publishes. But this solved it for me, it might

Upvotes: 0

hybrid
hybrid

Reputation: 1364

I spent too much time on this issue. Clean and Rebuild does not work for me.

What worked for me is deleting bin and obj folders from the Client(Blazor WASM) Project.

Environment

.Net 5 and 6

Visual Studio 2019 and 2022

Upvotes: 5

Hatef.
Hatef.

Reputation: 544

A better solution!

Open service-worker.js

change

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

to :

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

Now it works!

Upvotes: 0

Rui Lima
Rui Lima

Reputation: 7403

Just to leave here a note on something I came across while trying to figure out what was going on.

If for some reason you removed the service worker from your app and the resources were actually cached in the common http cache, there is a possibility that once you re-enable the service worker you will get this error, because the service worker will pick up the http cached version and not the server's.

What I did was to add cache: "no-cache" to the Request's init.

So my onInstall now looks something like this

async function onInstall(event) {
    console.info('Service worker: Install');

    // Fetch and cache all matching items from the assets manifest
    const assetsRequests = self.assetsManifest.assets
        .filter(asset => offlineAssetsInclude.some(pattern => pattern.test(asset.url)))
        .filter(asset => !offlineAssetsExclude.some(pattern => pattern.test(asset.url)))
        .map(asset => new Request(asset.url, { integrity: asset.hash, cache: "no-cache" }));
    
    // Also cache authentication configuration
    assetsRequests.push(new Request('_configuration/TestApp.Client'));

    await caches.open(cacheName).then(cache => cache.addAll(assetsRequests));
}

Upvotes: 2

Bozhidar Stoyneff
Bozhidar Stoyneff

Reputation: 3634

In my case, it was a wrong target framework in the publish profile - I should not have selected win-x64. I'm not sure of the exact reason, but the server interferes in some way with the response, based on the target framework. Just select browser-wasm and redeploy; it should be fine.

enter image description here

Upvotes: 8

devbf
devbf

Reputation: 571

Had the same problem today, in my case the error came with a css file. The problem was that I had two versions of my application deployed to local folders.

At first I started the old version, closed it and then opened up the new version. It seems that the old css file was cached in the browser which caused the error to appear.

The fix was simply pressing CTRL + U to open up the index.html file, clicking on the css file which caused the error and press F5 to reload the file. This solved the error for me.

Upvotes: 0

App Pack
App Pack

Reputation: 1532

In case someone else ends up here with the issue I had today..

I also got this error on a Blazor Wasm app locally after simple modification, and then still appeared after reverting changes.

The solution for me was to do a clean and rebuild.

Upvotes: 8

Autumn
Autumn

Reputation: 866

I found an answer here

Cause

Because I am using github pages to host my blazor app, it's using git to push up the code. Git by default will try to normalize line endings when committing code, which was causing the integrity of the blazor app to fail due to the files changing.

Solution

To fix this, I added a .gitattributes file to my blazor folder with * binary as the contents.

This tells git to treat all files as binary and therefore not to normalize the line endings. After I did that, I had to delete my _framework folder in my blazor app and rebuild it. After doing this, the blazor app worked.

Upvotes: 14

Kishan Rathod
Kishan Rathod

Reputation: 84

It looks like hash generated inside ServiceWorkerAssetsManifest for all the files and on the client side don't match. It looks like ServiceWorkerAssetsManifest is not generating hash again when the file is modified, specially the static files.

Upvotes: 1

Related Questions