ruby-on-rails – 在Rails应用程序上投放字体的Cloudfront CORS

发布时间：2020-12-16 20:01:45 所属栏目：百科来源：网络整理

导读：访问我的网站时,我从控制台继续收到此错误消息： 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

访问我的网站时,我从控制台继续收到此错误消息：

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.comz/,/Ahttps?://example-staging.herokuapp.comz/
]

但我认为阅读文字字符串更容易.

>配置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分发的“无效”选项卡并为*创建无效,来显式地使缓存的资产无效.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!