Michael Horton

I thought I would put my two cents in on this issue. I recently tried to use Font Awesome with Heroku and CloudFront on Rails 5 and faced a similar problem. Here's what I did to get it to work:

Installed rack-cors

gem 'rack-cors'

Configured rack-cors

config/initializers/rack-cors.rb

if defined? Rack::Cors
  Rails.configuration.middleware.insert_before 0, Rack::Cors do
    allow do
      origins %w[
        https://example.com
         http://example.com
        https://www.example.com
         http://www.example.com
        https://example.herokuapp.com
         http://example.herokuapp.com
      ]
      resource '/assets/*'
    end
  end
end

I preferred not to leave it wide open and just use the domains I knew I would hit it with.

Configure CloudFront

• https://console.aws.amazon.com/cloudfront/home#distributions
• select the distribution
• click Distribution Settings
• go to the Behaviors tab
• select the behavior (there will probably be only one)
• Click Edit
• Forward Headers: Whitelist
• Whitelist Headers: Select Origin and click Add >>
• Paste the following into the custom box one at a time and click Add Custom>>

Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Max-Age

After messing with this for over 6 hours, I think I messed it up even more. The last thing I did that finally made these settings stick was invalidate the CloudFront cache.

You can explicitly invalidate cached assets by going to the CloudFront distribution's Invalidations tab and creating an invalidation for *. I guess CloudFront cache sticks around longer than I had thought. This step took about 10 minutes. Yours might take less.

I used secrets.yml incorrectly this summer and my AWS account got hacked. Luckily I didn't have to pay the $31,000 back. lol. But because of that, it will probably be a long time before I use secrets.yml again. I'll just suffer through making sure all my local machines have matching env variables. I use Heroku for all production projects. But thanks for the info.

It does make sense.

Although I don't use secrets.yml, I use environment variables.

Also, it appears I'll have to do the same with IAM logins since we made the login specific to the bucket. I might just add the policy to the user for now...

Thanks.

I am using Shrine as you described in your Direct File Uploads to S3 episodes. It works fine, although I had to make a few minor tweaks to suit Bootstrap 4. One thing is troubling me: all files are going into one S3 bucket regardless of environment. I have a bucket created for Dev, Staging and Production, but I don't see in your episodes how to choose the buckets depending on environment. My only two thoughts are conditional statements in initializers/shrine.rb (which I don’t think I should) or move this block to the respective environments .rb files (which I don’t know if I can). Can I move the block over?

s3_options = {
  access_key_id:     ENV['AWS_ACCESS_KEY_ID'],
  secret_access_key: ENV['AWS_SECRET_ACCESS_KEY'],
  region:            ENV['S3_REGION'],
  bucket:            ENV['S3_BUCKET_NAME'],
}