Shopify_app: Valid digest error in request_storage_access javascript file on Heroku

[dansundy]

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

[AfolabiOlaoluwa]

I am using:
Ruby: 2.6.2
Rails: 6.0.0
Shopify App: config.api_version = "2019-10"

Rails 6 comes with sprockets v4.0.0. So I did as @dansundy suggested by adding gem 'sprockets', '~> 3.0' to me Gemfile, then I run bundle update sprockets which regressed sprockets to v3.7.0. It didn't work for me still.

[norioumata]

@dansundy I had the same issue but your solution helped me.
Thank you!

[ziaulrehman40]

I am on rails 6.0.1, ruby 2.6.5 and downgrading sprockets solved this issue. Though my css is not loading for some reason.

[AfolabiOlaoluwa]

I am on rails 6.0.1, ruby 2.6.5 and downgrading sprockets solved this issue. Though my css is not loading for some reason.

Yes CSS ain't loading

[ziaulrehman40]

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

[AfolabiOlaoluwa]

@ziaulrehman40 Adding stylesheet_link_tag and stylesheet_pack_tag actually result to 500 Error for me on Production. Here is the issue I opened regarding that. https://github.com/Shopify/shopify_app/issues/817

Also, you can check the source code here https://github.com/AfolabiOlaoluwa/ShopifyLoyaltyApp

However, I will look through your fix and how that could be possible with Webpack

[mizurnix]

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.

[AfolabiOlaoluwa]

@mizurnix you might wanna show how you added yours in Rails 6. Here is my embedded.html.erb. stylesheet_pack_tag just couldn't go in the if ShopifyApp.use_webpacker?, the app won't run for me.

[mizurnix]

@AfolabiOlaoluwa I think it should work both inside AND outside ShopifyApp.use_webpacker? since you are using webpack. I can confirm that in my case both variants work (tested in production as well).

This works:

    ...
    <%= stylesheet_pack_tag 'application' %>
    <% if ShopifyApp.use_webpacker? %>
      <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
    <% else %>
      <%= javascript_include_tag 'application', "data-turbolinks-track" => true %>
    <% end %>
    ...

So does this:

    ...
    <% if ShopifyApp.use_webpacker? %>
      <%= stylesheet_pack_tag 'application' %>
      <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
    <% else %>
      <%= javascript_include_tag 'application', "data-turbolinks-track" => true %>
    <% end %>
    ...

BTW, what do you mean with "app won't run"?

[AfolabiOlaoluwa]

Well, so here is the issue it results to here if I add:

<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= stylesheet_pack_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>

If I remove this stylesheet_pack_tag below, I do not get the webpack error:

<%#= stylesheet_pack_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>

However, pack/js/... still fires error and you can see the logs below despite assets precompiled. My app definitely needs stylesheet_pack_tag to be included.

I, [2019-12-05T22:09:45.975939 #46511]  INFO -- : [7b5c8e65-128b-4177-9c96-bf7d217d10b7] Started GET "/packs/js/application-58e919644efbaa8acad3.js" for 127.0.0.1 at 2019-12-05 22:09:45 +0100
F, [2019-12-05T22:09:45.980080 #46511] FATAL -- : [7b5c8e65-128b-4177-9c96-bf7d217d10b7]   
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] ActionController::RoutingError (No route matches [GET] "/packs/js/application-58e919644efbaa8acad3.js"):
[7b5c8e65-128b-4177-9c96-bf7d217d10b7]   
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] actionpack (6.0.1) lib/action_dispatch/middleware/debug_exceptions.rb:36:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] actionpack (6.0.1) lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] railties (6.0.1) lib/rails/rack/logger.rb:38:in `call_app'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] railties (6.0.1) lib/rails/rack/logger.rb:26:in `block in call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] activesupport (6.0.1) lib/active_support/tagged_logging.rb:80:in `block in tagged'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] activesupport (6.0.1) lib/active_support/tagged_logging.rb:28:in `tagged'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] activesupport (6.0.1) lib/active_support/tagged_logging.rb:80:in `tagged'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] railties (6.0.1) lib/rails/rack/logger.rb:26:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] actionpack (6.0.1) lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] actionpack (6.0.1) lib/action_dispatch/middleware/request_id.rb:27:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] rack (2.0.7) lib/rack/method_override.rb:22:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] rack (2.0.7) lib/rack/runtime.rb:22:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] activesupport (6.0.1) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] actionpack (6.0.1) lib/action_dispatch/middleware/executor.rb:14:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] rack (2.0.7) lib/rack/sendfile.rb:111:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] actionpack (6.0.1) lib/action_dispatch/middleware/host_authorization.rb:77:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] railties (6.0.1) lib/rails/engine.rb:526:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] puma (4.3.0) lib/puma/configuration.rb:228:in `call'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] puma (4.3.0) lib/puma/server.rb:667:in `handle_request'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] puma (4.3.0) lib/puma/server.rb:470:in `process_client'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] puma (4.3.0) lib/puma/server.rb:328:in `block in run'
[7b5c8e65-128b-4177-9c96-bf7d217d10b7] puma (4.3.0) lib/puma/thread_pool.rb:134:in `block in spawn_thread'

[isaacbowen]

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

Related discussions:

• https://github.com/rails/sprockets/issues/555
• https://github.com/rails/sprockets/pull/556
• https://github.com/rails/sprockets-rails/issues/393

[airhorns]

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!

[uurcank]

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

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

[tiagom87]

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

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

This worked for me

[paulbaudrier]

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

This doesn't work for me with Shopify_app 13.0.1 and rails 6
@tiagom87 @uurcankaya Have the gem 'sprockets' in gemfile.lock but how to disable the setting ?

[rafaelfranca]

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