Embed no longer works because of a bad integrity hash

Bug Reports
1

Hello,

All Runkit embeds are currently broken because of a bad integrity hash !

For example, this if I use this HTML code from the documentation on a page:

<h3 style="text-align: center;">Welcome to my website</h3>

<script src="https://embed.runkit.com" data-element-id="my-element"></script>

<!-- anywhere else on your page -->
<div id="my-element">// GeoJSON!
var getJSON = require("async-get-json");

await getJSON("https://storage.googleapis.com/maps-devrel/google.json");</div>

The embed doesn’t load, and instead I get these errors in the JS console:

image
image1171Ă—240 83.3 KB

JSFiddle with this example: Edit fiddle - JSFiddle - Code Playground

Are you aware of this problem?

2

Hi @bokub, this is working on every browser we are trying, including the example you linked to. What OS/browser/etc. are you using?

4

Hello,

My problem yesterday was with Google Chrome on Ubuntu.

Today, I still see the same problem with Chrome on Windows, but the embed works on Microsoft Edge, that’s weird…

I’ll investigate and keep you updated

Edit: The embed works on Google Chrome + private browsing, but not on regular browsing mode. I tried to disable all my extensions, and I still have the issue :thinking:

1 Like
5

Hi @tolmasky

I managed to understand the difference between the situations where Runkit embed works and the situations Runkit embed doesn’t work.

On situations where it works, the window-manager-...bundle.js file returns 21885 lines of code.

(link to image): https://global.discourse-cdn.com/flex030/uploads/tonicdev/original/2X/f/fd9982a6422fc9296c7b57c836612abe5a26fa10.png

However, for an unknown reason, on some of my browsers, the file stops at line 6947 in the network tab, but when I open the .js file in a new tab, I always get the 21885 lines version.

image
image2148Ă—1059 179 KB

Here is a diff you can inspect, the working version being on the left side: Runkit diff - Diff Checker

Do you have any idea why that happens, or how I could investigate even more ?

thanks

1 Like
6

Hi @bokub,

A couple quick questions:

  1. Does this reproduce every single time on the computer where it is not working? If so, maybe we could create a reduction (an Ubuntu container where we can get it to happen on our end, etc.). Given that it was happening in Ubuntu yesterday and Windows today, I imagine the answer is no here.
  2. When you inspect the file in the browser that doesn’t work, does the inspector say that this was a successful response (200, is the Content-Length header the smaller or bigger file size, does it show any sort of downloading error, etc.).
  3. Kind of scared to ask this because we might lose the state its in to be able to reproduce this, but you have tried previously to empty the browser cache/etc. and it kept happening? IOW, this isn’t some weird local cache state your browser is in, but something that repeatedly happens in the interaction between the browser and the server?

I’ll update here if I come up with more questions that could help us reproduce this.