正确的S3 + Cloudfront CORS配置？

Question 1

我的应用程序将图像存储在S3上，然后通过Cloudfront对其进行代理。我很高兴使用新的S3 CORS支持，以便可以使用HTML5 canvas方法（具有跨域策略），但似乎无法正确配置S3和Cloudfront。当我尝试将图像转换为画布元素时，仍然遇到“未捕获的错误：SECURITY_ERR：DOM异常18”。

这是我到目前为止的内容：

S3

<CORSConfiguration>
  <CORSRule>
    <AllowedOrigin>MY_WEBSITE_URL</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>*</AllowedHeader>
  </CORSRule>
  <CORSRule>
    <AllowedOrigin>MY_CLOUDFRONT_URL</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
    </CORSRule>
  </CORSConfiguration>

云前

起源

Origin Protocol Policy: Match Viewer

HTTP Port: 80

HTTPS Port: 443

行为举止

Origin: MY_WEBSITE_URL

Object Caching: Use Origin Cache Headers

Forward Cookies: None

Forward Query Strings: Yes

我在这里想念什么吗？

更新：刚刚尝试将标题更改为

<AllowedHeader>Content-*</AllowedHeader>
<AllowedHeader>Host</AllowedHeader>

基于此问题的Amazon S3 CORS（跨域资源共享）和Firefox跨域字体加载

还是不走。

更新：有关请求的更多信息

Request
URL:https://d1r5nr1emc2xy5.cloudfront.net/uploaded/BAhbBlsHOgZmSSImMjAxMi8wOS8xMC8xOC81NC80Mi85NC9ncmFzczMuanBnBjoGRVQ/32c0cee8
Request Method:GET
Status Code:200 OK (from cache)

更新

我认为我的要求可能不正确，因此我尝试通过以下方式启用CORS：

img.crossOrigin = '';

但随后图像无法加载，并且出现错误：跨域资源共享策略拒绝了跨域图像加载。

Question 2

2014年6月26日，AWS在CloudFront上发布了适当的Vary：Origin行为，现在您只需

为您的S3存储桶设置CORS配置，包括

<AllowedOrigin>*</AllowedOrigin>
在CloudFront->分配->此来源的行为中
- 允许的HTTP方法：+ OPTIONS
- 缓存的HTTP方法+ OPTIONS
- 基于所选请求Origin标头的缓存：将标头列入白名单。
等待约20分钟，然后CloudFront传播新规则

现在，您的CloudFront分发应该为不同的客户端Origin头缓存不同的响应（带有正确的CORS头）。

Question 3

补充@Brett的答案。有AWS文档页面详细介绍了上CloudFront的CORS和S3上CORS。

具体步骤如下：

在您的S3存储桶中，转到权限-> CORS配置
在编辑器中为CORS添加规则，该<AllowedOrigin>规则很重要。保存配置。
在您的CloudFront分配中，转到行为->选择行为->编辑
根据您是否要OPTIONS缓存响应，根据AWS，有两种方法：

如果要缓存OPTIONS响应，请执行以下操作：

选择默认缓存行为设置的选项，这些设置启用对OPTIONS响应的缓存。

配置CloudFront以转发以下标头：Origin，Access-Control-Request-Headers和Access-Control-Request-Method。

如果您不希望缓存OPTIONS响应，则将CloudFront配置为转发Origin标头以及源要求的其他标头

有了CloudFront，带有S3的CORS应该可以工作了。

Question 4

更新：CloudFront上的最新更改不再适用。pp！有关详细信息，请参见其他响应。我将其保留在此处以用于上下文/历史记录。

问题

CloudFront不支持100％的CORS。问题是CloudFront如何缓存对请求的响应。此后，对同一URL的任何其他请求都将导致缓存的请求，无论来源如何。关于它的关键部分是它包括来自起点的响应头。

CloudFront缓存了任何内容之前的第一个请求Origin: http://example.com的响应标头为：

Access-Control-Allow-Origin: http://example.com

来自的第二个请求Origin: https://example.com（请注意，它是HTTPS而不是HTTP）也具有以下响应标头：

Access-Control-Allow-Origin: http://example.com

因为那是CloudFront为URL缓存的内容。这是无效的-浏览器控制台（至少在Chrome中）将显示CORS违规消息，并且一切都会中断。

解决方法

建议的解决方法是对不同的来源使用不同的URL。诀窍是要添加一个唯一的查询字符串，该字符串要有所不同，以便每个源都存在一个缓存的记录。

因此，我们的网址将类似于：

http://.../some.png?http_mysite.com
https://.../some.png?https_mysite.com

这种工作方式有效，但是任何人都可以通过交换查询字符串来使您的网站无法正常工作。那可能吗？可能不是，但是调试此问题非常麻烦。

正确的解决方法是在CloudFront完全支持CORS之前，不要将CloudFront与CORS一起使用。

在实践中

如果您将CloudFront用于CORS，请使用其他方法，而在CORS不使用时，该方法将起作用。这并非总是一种选择，但现在我正在使用JavaScript动态加载字体。如果对CloudFront的基于CORS的请求失败，我将退回到字体的服务器端代理（不跨源）。这样，即使CloudFront以某种方式获得了不良的字体缓存记录，事情仍然可以正常进行。

Question 5

不完全确定您的问题是什么，但是：

https://forums.aws.amazon.com/thread.jspa?messageID=377513

使用CORS，S3和Cloudfront回答了我的一些问题。

我还发现，存储桶中的某些资产将返回正确的CORS标头，而某些资产则不会。在使资产无效之后，它们都以正确的标头返回，不确定为什么有些需要无效，而另一些则没有，因为它们是在同一时间，相同类型，相同存储桶中上传的:(

Question 6

作为对先前答案的补充，我想分享有关如何启用CORS的AWS步骤。我发现它非常有用，提供了其他链接：https : //aws.amazon.com/premiumsupport/knowledge-center/no-access-control-allow-origin-error/

另外，在测试更改时，除了CloudFront部署延迟外，您还应考虑的因素是浏览器缓存。建议您在测试更改时使用不同的会话进行隐身。