We Keep Coding

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

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.

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.

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.

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

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));
}

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.

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.

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!

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

Shopify App - Using Script Tags with Ruby on Rails Application

I'm trying to familiarize myself with the concept of using script tags. I'm making a ruby on rails app that does something as simple as alert "Hi" when a customer visits a page. I am testing this public app on a local server and I have the shopify_app gem installed. The app has been authenticated and I have access to the store's data. I've viewed the Shopify API documentation on using script tags and I've looked at the Shopify Embedded App example that Shopify has on GitHub. The documentation details the properties of a script tag and gives examples of script tags with their properties defined, but doesn't say anything about where to place the script tag in an application, or how to configure an environment so that the js file in the script tag will go through.
I've discovered that a js file being added with a script tag will only work if the js file is hosted online, so I've uploaded the js file to google drive. I have the code for the script tag in the index action of my HomeController (the default page for the app). This is the code I'm using:
def index
if response = request.env['omniauth.auth']
sess = ShopifyAPI::Session.new(params[:shop], response[:credentials][:token])
session[:shopify] = sess
ShopifyAPI::Base.activate_session(sess)
ShopifyAPI::ScriptTag.create(
:event => "onload",
:src => "https://drive.google.com/..."
)
end
I think the problem may be tied to the request.env. The response is not being read as request.env[omniauth.auth] and I believe that the response coming back as valid may be required for the script tag to go through.
The method that I tried above is from the 2nd answer given in this topic: How to develop rails app for shopify with ScriptTags.
The first answer suggested using this code:
ShopifyAPI::Base.site = token
s = ShopifyAPI::ScriptTag.create(:events => "onload",:src => "your javascript url")
However, it doesn't say where to place both lines of code in a rails application. I tried putting the second line in a js file in my rails application, but it did not work.
I don't know if I'm encountering problems because I'm running the app on a local server or if there is something missing from the configuration of my application.
I'd appreciate it if anyone could point me in the right direction.

Try putting something like this in config/initializers/shopify_app.rb
ShopifyApp.configure do |config|
config.api_key = "xxx-xxxx-xxx-xxx"
config.secret = "xxx-xxxx-xxx-xxx"
config.scope = "read_orders, read_products"
config.embedded_app = true
config.scripttags = [
{event:'onload', src: 'https://yourdomain.herokuapp.com/javascripts/yourjs.js'}
]
end
Yes, you are correct that you'll need the js file you want to include for your script tag publicly available - if you are using localhost for development look into ngrok.
Do yourself the favor of ensuring your callbacks use SSL when interacting with the Shopify API (i.e. configure your app with https://localhost/ as a callback setting in the Shopify app settings). I went through the trouble of configuring thin as the web server locally with a self-signed SSL certificate.
With a proper set up you should be able to debug why the response is failing the omniauth check.
I'm new to the Shopify API(s), but not Rails. Their documentation leaves a lot to be desired.
Good luck to you sir,

Pimcore: Getting the White-Screen-of-Death after successful admin login

I've installed Pimcore on a VPS through Liquid Web. I loaded the sample data install which also uses the nightly build code. While everything installed fine, the public facing website appears fine and functions well, as does the login screen for the admin panel, once you log in, you see three black pulsing dots in the middle of a white screen, where eventually they disappear and you're simply left with a white screen.
Upon inspection of the error console, I'm seeing this error:
Failed to load resource: the server responded with a status of 404 (Not Found)
/website/var/tmp/minified_javascript_core_b18dd1d6984052da2ab5abc79f0c4a17.js?_dc=3704
Other scripts are also failing because this script isn't being loaded, so I'm fairly sure that once this script loads the others will work just fine.
When I try to directly access this JS file, I see this message:
HTTP/1.1 404 Not Found Filtered by error handler (static file exception)
I have verified that the file exists in the filesystem, so I know for sure that it's there, leading me to believe that the filesystem has that directory and/or file locked down. Permissions etc, are all set to their appropriate values.
Pimcore Version 4

It's been a few years and this project surfaced in our pipeline again. The actual cause for why this breaks was because we are also running the ModSecurity suite on our host. Accessing the interface .js file was triggering rule 2000009 where the pattern /var/tmp was being matched.
Possible solution (if you're using WHM/CPanel as we are):
Configure your /etc/apache2/conf.d/modsec2/whitelist.conf file to include the following rule (add more in the same place if needed).
<LocationMatch '/website'>
SecRuleRemoveById 2000009
</LocationMatch>
Be sure that you restart your HTTP service after making this update.
Enjoy!

Cannot make Meteor/Cordova use a remote server for DDP

I've been trying to solve the following problem for a few days now, and it's been driving me absolutely crazy.
I have a (1.2) meteor application, deployed at http://some.application.com:3000. It works great, and does what it is supposed to do. The application uses several packages, the ones that I think are related to this issue are autoupdate and the accounts package (which loads its own bunch of stuff).
Our directive is to turn this webapp into an android app, something we've been told meteor can do "quite easily". On the surface it seems like it's a simple case of meteor run android-device --mobile-server http://some.application.com:3000 --settings settings.json --verbose, however this doesn't do what I expect it to do.
Meteor decides to do the DDP connection on 10.0.2.2 (for whatever reason), and no matter what env variables I set I end up in the same situation.
It's important to note that the application has not been written using the DDP.connect(url) method anywhere [docs], so everything relies on the primary DDP connection (which I suspect might be one of the bigger causes of our problem).
For the record, here is my startup script. I got pretty desperate and added many, many env vars, and haven't had any luck for any combination thereof.
#!/bin/bash
export AWS_REGION=xxx
export AWS_BUCKET=xxx
export MONGO_URL=mongodb://some.application.com:27017/application
export QUEUE_ADDRESS=http://some.application.com
export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=xxx
export ROOT_URL=http://some.application.com:3000
export DDP_DEFAULT_CONNECTION_URL=http://some.application.com:3000
export MOBILE_DDP_URL=http://some.application.com:3000
export MOBILE_ROOT_URL=http://some.application.com:3000
# Let's go
meteor run android-device --mobile-server http://some.application.com:3000 --settings settings.json --verbose
Running it locally, on mobile or desktop, (via localhost:3000 with port forwarding, or any other internal IP (10.x.x.x, 192.x.x.x) works absolutely fine. It even works with the remote AWS, Queue and DB.
According to all the documentation the --mobile-server switch should sort things out. It doesn't. I've tried it with and without an =, wrapped in quotes, all possible ways of defining it.
Looking at the <head> of my document I see the following code getting injected
__meteor_runtime_config__ = JSON.parse(decodeURIComponent("%7B%22meteorRelease%22%3A%22METEOR%401.2.0.2%22%2C%22PUBLIC_SETTINGS%22%3A%7B%22verifiedLogin%22%3Afalse%2C%22enableFacebookAuth%22%3Afalse%2C%22enableTwitterAuth%22%3Afalse%2C%22enableGoogleAuth%22%3Afalse%2C%22cdnUrlWithTrailingSlash%22%3A%22http%3A%2F%2Fdev.cdn.some.application.com%2F%22%2C%22ga%22%3A%7B%22id%22%3A%22UA-XXXXXX-1%22%7D%7D%2C%22ROOT_URL%22%3A%22http%3A%2F%2Flocalhost%3A3000%22%2C%22ROOT_URL_PATH_PREFIX%22%3A%22%22%2C%22appId%22%3A%228emj6c37j3fdoz5qmp%22%2C%22accountsConfigCalled%22%3Atrue%2C%22autoupdateVersion%22%3A%222b3acf7aa3ddef802ddf661d3b3986319aad5122%22%2C%22autoupdateVersionRefreshable%22%3A%22b00197cdb5345434d03d9a2503906349ff7854e2%22%2C%22autoupdateVersionCordova%22%3A%223644168d46bc4597d0b2d8c39e366890f6725f52%22%2C%22DDP_DEFAULT_CONNECTION_URL%22%3A%22http%3A%2F%2Flocalhost%3A3000%22%7D"));
if (/Android/i.test(navigator.userAgent)) {
// When Android app is emulated, it cannot connect to localhost,
// instead it should connect to 10.0.2.2
// (unless we're using an http proxy; then it works!)
if (!__meteor_runtime_config__.httpProxyPort) {
__meteor_runtime_config__.ROOT_URL = (__meteor_runtime_config__.ROOT_URL || '').replace(/localhost/i, '10.0.2.2');
__meteor_runtime_config__.DDP_DEFAULT_CONNECTION_URL = (__meteor_runtime_config__.DDP_DEFAULT_CONNECTION_URL || '').replace(/localhost/i, '10.0.2.2');
}
}
The UrlDecoded version of that string is as follows
{
"meteorRelease": "METEOR#1.2.0.2",
"PUBLIC_SETTINGS": {
"verifiedLogin": false,
"enableFacebookAuth": false,
"enableTwitterAuth": false,
"enableGoogleAuth": false,
"cdnUrlWithTrailingSlash": "http://dev.cdn.application.com/",
"ga": {
"id": "UA-XXXXXX-1"
}
},
"ROOT_URL": "http://localhost:3000",
"ROOT_URL_PATH_PREFIX": "",
"appId": "jfdjdjdjdjdjjdjdjdjjd",
"accountsConfigCalled": true,
"autoupdateVersion": "2b3acf7aa3ddef802ddf661d3b3986319aad5122",
"autoupdateVersionRefreshable": "b00197cdb5345434d03d9a2503906349ff7854e2",
"autoupdateVersionCordova": "3644168d46bc4597d0b2d8c39e366890f6725f52",
"DDP_DEFAULT_CONNECTION_URL": "http://localhost:3000"
}
This is strange because I have no entries of localhost anywhere.
Booting the app tells me: App running at: http://site.some.application.com, but no connections are made in the network inspector.
Grepping through the code shows me that the only places where __meteor_runtime_config__ is mentioned is in the autoupdate package.
Further investigation lead me to this issue #3815 which linked to this fix, but after I implemented it (the changes to the autoupdate package) I was still faced with the same problem (although hot code fixes stopped coming through from my local machine)
Even more investigation lead me to believe that the remote DDP server could be changed like this, but unfortunately this solution doesn't work with Cordova.
I tried settings HTTP_PROXY as the comment "unless we're behind a proxy" in the <head> script lead me to believe this might be a quick fix, but I didn't have any luck with this.
I tried removing the accounts package, but have not had any luck in this regard.
Main Question Is there any suggested way to allow a Cordova wrapped Meteor application to connect to an arbitrary server, and allow a DDP connection to same?
The accounts package is (most likely) needed. I suppose auto-updates aren't thaaat crucial, although they do help in terms of not having to regularly release code to the various app stores.
Things I've tried:
Removing accounts package
Remove autoupdates
Modifying autoupdates to point to remote DDP
Using the remote-ddp package
Forcing __meteor_runtime_config__ overrides
Setting a proxy
Environment variables
And several other thousand things
Related issues (Going back to Jan 2015) are:
How can DDP_DEFAULT_CONNECTION_URL be set? #3852 - Shows difficulty in connecting to remote meteor servers, and touches on how the autoupdate package affects things.
Dont' start local server when using option --mobile-server #3727 - This shows a case of the --mobile-server becoming 10.0.2.2
Meteor mobile build is not changing DDP_DEFAULT_CONNECTION_URL #4396 - This shows an apparent fix, but this doesn't work for me at all
Ability to pass an alternative DDP connection to autoupdate #3815 - This shows the confusion that comes from the official documentation, and lead me to the autoupdate package "fix" that I linked earlier
MOBILE_ROOT_URL and MOBILE_DDP_URL are ignored on meteor build #4581 - This shows how meteor build ignores these env vars
Can't build mobile app with different DDP server #4412 - This shows others having difficulty with the same problem, with the response asking for PRs around the issue
Meteor Accounts only authenticates DDP, not HTTP #3390 - This shows that auth via meteor-accounts can only happen via DDP, and not HTTP
Built apps cannot connect to the given --server: they keep failing to connect #3698 - This shows other users having the same issue on iOS, although they do report having success with connecting to a local server, which I also have success with, but there is no mention of success with a remote server. The fix appears to be deploying through meteor to some-app.meteor.com but this isn't an option for us.
Contents of .meteor/packages
aldeed:autoform#=4.2.2
aldeed:collection2#2.5.0
aldeed:simple-schema#1.3.3
aldeed:tabular#1.4.1
autoupdate#1.2.3
biasport:facebook-sdk#0.2.2
blaze#2.1.3
check#1.0.6
edgee:slingshot#0.7.1
iron:router#1.0.12
jquery#1.11.4
juliancwirko:s-alert#3.1.1
juliancwirko:s-alert-slide#3.1.0
lookback:seo#1.1.0
matteodem:easy-search#1.6.4
meteor#1.1.9
meteorhacks:fast-render#2.10.0
meteorhacks:subs-manager#1.6.2
mobile-experience#1.0.1
momentjs:moment#2.10.6
mquandalle:jade#0.4.4
multiply:iron-router-progress#1.0.2
---
internal packages (one of which includes accounts)
---
reactive-dict#1.1.2
reactive-var#1.0.6
reywood:iron-router-ga#0.7.1
session#1.1.1
standard-minifiers#1.0.1
templating#1.1.4
tracker#1.0.9
underscore#1.0.4
underscorestring:underscore.string#3.2.2
utilities:avatar#0.9.2
I can provide the contents of my versions file if you feel that will help.
TL;DR - Is there any suggested way to allow a Cordova wrapped Meteor application to connect to an arbitrary server, and allow a DDP connection to same?
Any help or pointers around this issue would be much appreciated. Please let me know if there is any other information you may need to assist in this regard.
Many thanks
Issue On Github

Using iframe with local files in Chrome

I am having a tough time figuring out how to access a page loaded in an iframe from the outer page. Both pages are local files, and I'm using Chrome.
I have an outer page, and many inner pages. The outer page should always display the page title for the inner page (it makes sense in my application, perhaps less so in this stripped-down example). This works without any problem in AppJS, but I've been requested to make this app work directly in the browser. I'm getting the error "Blocked a frame with origin "null" from accessing a frame with origin "null". Protocols, domains, and ports must match.".
I think this is due to Chrome's same origin policy regarding local files, but that hasn't helped me fix the problem directly. I can work around the issue in this stripped-down example by using the window.postMessage method per Ways to circumvent the same-origin policy. However, going beyond this example, I also want to manipulate the DOM of the inner page from the outer page, since this will make my code much cleaner - so posting messages won't quite do the job.
Outer Page
<!DOCTYPE html>
<html>
<head>
<meta name="viewport">
</head>
<body>
This text is in the outer page
<iframe src="html/Home.html" seamless id="PageContent_Iframe"></iframe>
<script src="./js/LoadNewPage.js"></script>
</body>
</html>
Inner Page
<!DOCTYPE html>
<html>
<head>
<title id="Page_Title">Home</title>
<meta name="viewport">
</head>
<body>
This text is in the inner page
</body>
</html>
JavaScript
var iFrameWindow = document.getElementById("PageContent_Iframe").contentWindow;
var pageTitleElement = iFrameWindow.$("#Page_Title");
Per Is it likely that future releases of Chrome support contentWindow/contentDocument when iFrame loads a local html file from local html file?, I tried launching Chrome with the flag
--allow-file-access-from-files
But there was no change in the results.
Per Disable same origin policy in Chrome, I tried launching Chrome with the flag
--disable-web-security
But again there was no change in the results.
Per What does document.domain = document.domain do?, I had both pages run the command
document.domain = document.domain;
This resulted in the error "Blocked a frame with origin "null" from accessing a frame with origin "null". The frame requesting access set "document.domain" to "", but the frame being accessed did not. Both must set "document.domain" to the same value to allow access."
For fun, I had both pages run the command
document.domain = "foo.com";
This resulted in the error "Uncaught Error: SecurityError: DOM Exception 18".
I'm floundering. Any help from more knowledgeable people would be fantastic! Thanks!

I'm sorry to say you that I've tried during weeks to solve this issue (I needed it for a project) and my conclusion is that it's not possible.
There are a lot of problems arround local access through javascript with chrome, and some of them can be solved using --allow-file-access-from-files and --disable-web-security, including some HTML5 offline features, but I definitely think there's no way to access local files.
I recomend you not to lose your time trying to circunvend this and to try to post messages wich you can interpret into the inner pages, so you can do the DOM modifications there.

Per our discussion in my cube just a minute ago :)
I hit this same problem (Ajax post response from express js keeps throwing error) trying to get an AJAX post request to work correctly.
What got me around it is not running the file directly off the file system but instead running it from a local server. I used node to run express.js. You can install express with the following command: npm install -g express
Once that is accomplished, you can create an express project with the following command: express -s -e expressTestApp
Now, in that folder, you should see a file named app.js and a folder named public. Put the html files you wish to work with in the public folder. I replaced the file app.js with the following code:
var express = require('/usr/lib/node_modules/express');
var app = express();
app.use(function(err, req, res, next){
console.error(err.stack);
res.send(500, 'Something broke!');
});
app.use(express.bodyParser());
app.use(express.static('public'));
app.listen(5555, function() { console.log("Server is up and running"); });
Note, the require line may be different. You have to find where your system actually put express. You can do that with the following command: sudo find / -name express
Now, start the express web server with the following command: node app.js
At this time, the webserver is up and running. Go ahead and open a browswer and navigate to your ip address (or if you're on the same machine as your server, 127.0.0.1). Use the ip address:portnumber\filename.html where port number is the 5555 in the app.js file we created.
Now in that browser, you shouldn't (and didn't when we tested it) have any of these same problems anymore.

file:// protocol and http:// protocol make things to behave very differently in regards to iframes. I had the same issues you describe with an app on PhoneGap which uses file protocol to access all local files within the local assets/www folder.
If seems that modern browsers prevent the display of "local" files using the file protocol in iframes for security reasons.
We ended up dumping iframes and just using divs as "viewports". Fortunately the overall size of our app was not that big so we managed to load everything in a single page.