font from origin 'https://xxx.cloudfront.net' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.example.com' is therefore not allowed access.
我试过一切：
>我已经安装了font_assets gem
>配置了application.rb文件
config.font_assets.origin = 'http://example.com'
> this article至2007年所述,Cloudfront上的白名单标题
Access-Control-Allow-Origin Access-Control-Allow-Methods Access-Control-Allow-Headers Access-Control-Max-Age
但没有,零,纳达.
我在Heroku上使用Rails 4.1.
解决方法
> CloudFront镜像我们的Rails应用程序的响应标题的事实需要你扭转你的想法. CORS协议很难理解,但现在您必须在两个层面上进行跟踪：浏览器和CloudFront之间(当我们的Rails应用程序将其用作CDN时)以及浏览器和Rails应用程序之间(当一些恶意网站想滥用我们).
CORS真的是关于浏览器和网页想要访问的第三方资源之间的对话. (在我们的用例中,这是CloudFront CDN,为我们的应用程序提供资产).但是,由于CloudFront从我们的应用程序获取了Access-Control响应标头,因此我们的应用程序需要像CloudFront聊天那样为这些标题提供服务,同时不会授予许可权,使自身受到导致同源政策/ CORS的滥用类型的开发.特别是,我们不应该在我们的网站上授予*访问*资源.
>我在那里发现了太多过时的信息 – 一个无休止的博客文章和SO线程. CloudFront已经大大改进了CORS支持,因为许多帖子虽然还不完善. (CORS应该真正处理开箱即用).宝石本身也在发展.
我的设置：Rails 4.1.15在Heroku上运行,从CloudFront提供资产.我的应用程序同时响应http和https两个“www”.和区域顶点,而不做任何重定向.
我简单地看了问题中提到的font_assets宝石,但很快就放弃了支架,这似乎更重要.我不想简单地打开所有起源和所有路径,因为这将打破CORS的要点和同源策略的安全性,所以我需要能够指定我允许的几个起源.最后,我个人喜欢通过个人配置/初始化/ * .rb文件配置Rails,而不是编辑标准的配置文件(如config.ru或config / application.rb)将所有的一切放在一起,这是我的解决方案,我相信最好的可用,从2014年4月16日：
> Gemfile
gem "rack-cors"
机架宝石在Rack中间件中实现CORS协议.
除了在批准的起始点设置Access-Control-Allow-Origin和相关标题之外,还添加了一个Vary：Origin响应头,指示CloudFront分别缓存每个源的响应(包括响应头).当我们的网站可以通过多个来源访问(例如通过http和https,以及通过“www.”和裸机域)时,这一点至关重要.
> config / initializers / rack-cors.rb
## Configure Rack CORS Middleware,so that CloudFront can serve our assets.
## See https://github.com/cyu/rack-cors
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-staging.herokuapp.com
http://example-staging.herokuapp.com
]
resource '/assets/*'
end
end
end
这告诉浏览器,它可以访问我们的Rails应用程序(并且扩展,在CloudFront上,因为它是镜像我们)的资源,只代表我们的Rails应用程序(而不是代表恶意 – 网站),只有/资产/网址(而不是我们的控制器).换句话说,允许CloudFront提供资产,但不要再打开门.
笔记：
>我尝试在机架超时后插入,而不是在中间件链的头部.
它在开发工作,但不是踢在Heroku,尽管
具有相同的中间件(Honeybadger除外).
>起源列表也可以作为Regexps来完成.
注意在字符串末尾处锚定图案.
origins [
/\Ahttps?:\/\/(www\.)?example\.com\z/,/\Ahttps?:\/\/example-staging\.herokuapp\.com\z/
]
但我认为阅读文字字符串更容易.
>配置CloudFront将浏览器的Origin请求标头传递到我们的Rails应用程序.
奇怪的是,CloudFront似乎将Origin标头从浏览器转发到Rails应用程序,无论我们是否在这里添加,但是只有当Origin被明确添加到标题白名单时,CloudFront才会尊重我们应用程序的Vary：Origin缓存指令(截至2016年4月).
请求头白列表是一种埋葬.
如果分发已经存在,您可以在以下位置找到它：
> https://console.aws.amazon.com/cloudfront/home#distributions
>选择分配
>点击分发设置
>转到“行为”选项卡
>选择行为(可能只有一个)
>单击编辑
>转发标题：白名单
>白名单标题：选择原点,然后单击添加>>
如果您尚未创建发行版,请创建：
> https://console.aws.amazon.com/cloudfront/home#distributions
>单击创建分发
(为了完整性和可重复性,我列出了我从默认值中更改的所有设置,但是白名单设置是唯一与此讨论相关的设置)
传递方式：Web(不是RTMP)
>原始设置
>原产地域名：example.com
>原始SSL协议：TLSv1.2 ONLY
>原始协议策略：仅限HTTPS
>默认缓存行为设置
>查看器协议策略：将HTTP重定向到HTTPS
>转发标题：白名单
>白名单标题：选择原点,然后单击添加>>
自动压缩对象：是的
在更改所有这些事情之后,请记住,任何旧的缓存值都可能需要一些时间才能从CloudFront过期.您可以通过转到CloudFront分发的“无效”选项卡并为*创建无效,来显式地使缓存的资产无效.