shopify_app: Valid digest error in request_storage_access javascript file on Heroku

After doing gem updates I started getting the following error for the request_storage_access file in production (a Heroku staging server) only:

Failed to find valid digest in the 'integrity' attribute for for resource 'https://[myapp]/assets/shopify_app/request_storage_access-[hash].js' with computed SHA-265 integrity '[different-hash]'. The resource has been blocked.

It looks like this error happened because I updated Sprockets to 4.0.0 and may be related to this very old but still open issue in sprockets-rails: https://github.com/rails/sprockets-rails/issues/393. It looks like I have fixed the issue temporarily by downgrading Sprockets to 3.7.2 by adding gem 'sprockets', '~> 3.0' to my Gemfile.

I also noticed this issue which may be related. But I can confirm that my assets were compiling properly when deploying to Heroku. I wasn’t getting 404 errors.

As mentioned, it looks like I have resolved this temporarily but thought I’d flag the issue in case others were running into it and because it may come up more often in the future.

Environment info:

Browser: Chrome Version 78.0.3904.70 (Official Build) (64-bit) OS: MacOS Mojave 10.14.6 Ruby: 2.5.7 Rails: 5.2.3 Shopify App: 11.2.0

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 20
Comments: 16 (2 by maintainers)

Most upvoted comments

I think it might be wise to change the javascript_include_tag to not pass the :integrity option until the upstream bug is fixed in Sprockets, or else everyone’s initial Rails 6 apps are going to be broken with this issue that each dev has to dig up and fix. It’s an elective feature that enhances security but a secure broken app is not very useful in comparison to a slightly less secure actually working app if you ask me.

Also FWIW if you are going to apply the Rails.application.config.assets.version = '' fix in an initializer, it’s worth checking if any other railties are setting that version to be something, because some do and do it after files in config/initializers run. react-rails for example sets the value at this time, so to override it I added this to my config/application.rb:

    config.after_initialize do
      Rails.application.config.assets.version = ""
    end

which is even gross-er, but hey, at least I can access the application!

+12

airhorns on Jan 24, 2020

I’m working around this with Rails.application.config.assets.version = '', in my config/initializers/assets.rb, with sprockets 4 and rails 6. This works becaaauuuse:

https://github.com/rails/sprockets/blob/08fef08562c7a6a13a7c521938e83409a33e2b77/lib/sprockets/loader.rb#L198

We’re using digests in asset urls, so (unless I’m missing something) it’s totally unnecessary for us to have version as a mechanism for expiring assets. Plus, now our integrity hashes work. 😄

Related discussions:

+11

isaacbowen on Dec 21, 2019

Cloudflare’s auto-minify setting causes this problem. It works after disabling that setting.

Rails 6
gem 'sprockets', '~> 3.0'

uurcank on Apr 14, 2020

@AfolabiOlaoluwa I fixed css loading issue on my end, it was missing stylesheet_pack_tag see https://gist.github.com/ziaulrehman40/19c87cc73dd75ce6e5d717ace8ddcc48#gistcomment-3099095 for detail. Might be same issue in your case as well.

ziaulrehman40 on Dec 3, 2019

This issue should be fixed now with sprockets 4.0.1. Let me know if you still have a problem and I’ll reopen.

rafaelfranca on Jun 5, 2020

Seems like quite a few developers (including me) are building their first Rails 6 app with shopify_app gem right now, and because of the request_storage_access issue, many of us came across the CSS not being loaded issue right after “solving” request_storage_access.

Some may even think these two issues are somehow related. I believe that’s not the case at all - according to README:

In order to have styles load in production, you need to include stylesheet_pack_tag with the same name as the javascript file that imports the styles.

mzrnsh on Dec 5, 2019