AWS:如何在 S3 CORS 配置中允许多个域? [英] AWS: How can I allow multiple domains in an S3 CORS configuration?

问题描述

我的许多站点都遇到了问题，这些站点依赖 S3 作为 Cloudfront 的源.但是，我在允许多个域(而不是允许全局 *)方面遇到问题.

I've been having an issue across many of my sites that rely on S3 as an origin for Cloudfront. However, I'm having issues with allowing multiple domains (instead of a global * allowed).

我已经按照文档这里(第一次配置).并在这里和那里找到了其他一些随机的 SO 或论坛答案(第二个配置)

I have followed the documentation here (first config). And found a few other random SO or forum answers here and there (second config)

感谢任何帮助.

我设置的 CORS 规则如下所示:

I have setup CORS Rules that look like both of the following:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>https://example.com</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <AllowedMethod>HEAD</AllowedMethod>
        <AllowedMethod>DELETE</AllowedMethod>
        <AllowedMethod>PUT</AllowedMethod>
        <AllowedMethod>POST</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Authorization</AllowedHeader>
    </CORSRule>
    <CORSRule>
        <AllowedOrigin>http://example.com</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
    <CORSRule>
        <AllowedOrigin>https://staging.example.com</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
    <CORSRule>
        <AllowedOrigin>http://example.dev</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

AND

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>https://example.com</AllowedOrigin>
        <AllowedOrigin>http://example.com</AllowedOrigin>
        <AllowedOrigin>https://staging.example.com</AllowedOrigin>
        <AllowedOrigin>http://example.dev</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <AllowedMethod>HEAD</AllowedMethod>
        <AllowedMethod>DELETE</AllowedMethod>
        <AllowedMethod>PUT</AllowedMethod>
        <AllowedMethod>POST</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Authorization</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

我在所有网站上都出现字体来源错误除了 https://example.com:

I keep getting the font origin error on all sites except https://example.com:

来自源的字体http://CLOUDFRONTURL"已被跨源资源共享策略阻止加载:无访问"-Control-Allow-Origin' 标头存在于请求的资源上.因此不允许访问源 'http://example.dev'.

Font from origin 'http://CLOUDFRONTURL' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://example.dev' is therefore not allowed access.

和

来自源的字体http://CLOUDFRONTURL"已被跨源资源共享策略阻止加载:访问-Control-Allow-Origin' 标头的值 'https://example.com' 不等于提供的起源.因此不允许访问源 'http://example.dev'.

Font from origin 'http://CLOUDFRONTURL' has been blocked from loading by Cross-Origin Resource Sharing policy: The 'Access-Control-Allow-Origin' header has a value 'https://example.com' that is not equal to the supplied origin. Origin 'http://example.dev' is therefore not allowed access.

推荐答案

CloudFront 缓存对象基于所有从浏览器转发到源服务器的请求标头——而不仅仅是路径.

CloudFront caches objects based the all of the request headers that it has forwarded from the browser to the origin server -- not just the path.

对于要从缓存中提供的响应，它必须在响应包含完全相同请求标头的先前请求时返回.

For a response to be served from the cache, it must have been returned in response to a previous request that involved exactly the same request headers.

这是因为，至少原则上，不同的标头可以触发服务器的不同行为，而行为良好的缓存不能随意假设.

This is because, in principle at least, different headers can trigger different behavior by the server, and a well-behaved cache is not at liberty to assume otherwise.

为了提高对象的可缓存性，同时又不影响其提供正确响应的能力(即，源服务器将为给定请求返回的相同响应)，CloudFront 在此之前去除了几乎所有请求标头将请求转发到源，并在进行缓存查找时使用请求的剥离版本.

To increase the cacheability of objects without compromising its ability to serve correct responses (that is, identical response the origin server would have returned for a given request), CloudFront strips almost of the request headers before forwarding the request to the origin, and uses the stripped version of the request when doing cache lookups.

当源服务器是自定义"(即，不是 S3)源时，您可以选择将哪些标头转发到源服务器.

When the origin server is a "Custom" (i.e., not S3) origin, you can choose which headers to forward to the origin server.

但是当源站是S3的时候，你还是有选择的，但是可以选择转发的只有三个……而且都是CORS相关的.

But when the origin server is S3, you still have choices, but there are only three that can be optionally forwarded... and they are all CORS related.

[使用 S3 源，]您可以将 CloudFront 配置为仅基于三个标头转发和缓存您的对象:Access-Control-Request-Headers、Access-Control-Request-方法和Origin.转发这些标头允许 CloudFront 为启用跨源资源共享 (CORS) 的网站分发内容.您无法将 CloudFront 配置为将自定义标头转发到 Amazon S3.

[With an S3 origin,] you can configure CloudFront to forward and to cache your objects based only on three headers: Access-Control-Request-Headers, Access-Control-Request-Method, and Origin. Forwarding these headers allows CloudFront to distribute content for websites that are enabled for cross-origin resource sharing (CORS). You can't configure CloudFront to forward custom headers to Amazon S3.

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web

如果 Origin: 标头至少没有被转发，那么 S3 将无法对其做出反应.启用此标头的转发意味着 S3 不仅会看到它，并且可能会因为存储桶上的 CORS 配置而修改其响应，而且 Origin: 的每个变体 - 对于同一对象 -- 将导致 S3 返回不同(且正确)的响应并缓存以供 CloudFront 将来匹配请求.

If the Origin: header, at least, doesn't get forwarded, then S3 will not be able to react to it. Enabling forwarding of this header means that not only will S3 see it, and potentially modify its response because of the CORS configuration on the bucket, but also that each variation of Origin: -- for the same object -- will result in a different (and correct) response being returned by S3 and cached for future matching requests by CloudFront.

CloudFront 无法将自定义标头转发到 S3，因为这没有任何用处——因为 S3 存储静态内容，响应不会因其他标头而异，因此转发它们将毫无意义并且会降低缓存命中率, 缓存了许多(据说)不同的响应，但仅在响应带有相同标头的请求时才提供服务.

Custom headers can't be forwarded to S3 by CloudFront because this would serve no purpose -- since S3 stores static content, responses wouldn't vary on other headers, so forwarding them would be pointless and would reduce the cache hit rate, with many (supposedly) different responses being cached, but only being served in response to requests that were accompanied by identical headers.

这篇关于AWS:如何在 S3 CORS 配置中允许多个域?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！