我有一个具有以下CORS策略的AWS S3存储桶:
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
<ExposeHeader>Access-Control-Allow-Origin</ExposeHeader>
</CORSRule>
</CORSConfiguration>
在我的应用中,我从存储桶中加载了一张图像。图像按预期显示在页面上。当我单击其中一张图像以在Adobe Creative SDK中将其打开时,SDK无法加载图像,因为它被CORS阻止了。SDK会获取图片的网址,并通过AJAX加载图片。该SDK有一个启用CORS的选项,并且似乎正在发送正确的Origin
标头(请参见屏幕截图),但是AWS不包含Access-Control-Allow-Origin-Header
,导致图像被CORS阻止。
我在这里搜寻了关于该主题的每个问题,似乎没人能直接回答。关于这个主题,有数十个问题尚未解决,但是在许多情况下,似乎AJAX请求没有发送Origin标头或存储桶配置不正确。在这种情况下,都不是真的,这就是为什么这不是重复的原因。
如您在屏幕快照中所见,请求包含Origin
标头,但响应不包含Access-Control-Allow-Origin
标头。我想知道的是:1.如果我的存储桶配置正确,为什么S3没有发送正确的报头?2.当Adobe Creative SDK通过AJAX请求图像时,浏览器是否可能看到该图像已被缓存,并尝试提供该缓存的图像(没有Origin
标题)?3.如果是#2,如何将Origin
标头强制添加到图像请求中?在应用程序中,图像是div(cssbackground-image
属性)的背景。
我创建了一个测试桶,启用了CORS,并使用了您的CORS规则。
请注意,我不认为这<ExposeHeader>Access-Control-Allow-Origin</ExposeHeader>
是必要的,但是它的存在不应该造成任何伤害,因此我保留了它。
我在测试中观察到的行为与浏览器的请求/响应标头中显示的行为不一致。
使用curl,将Origin:
标头设置为http://example.com
。(是的,这实际上是我将其设置为...在下面的输出中未对此进行修改)。
$ curl -v http://xxxxxxxxxxxx.s3.amazonaws.com/index.txt -H 'Origin: http://example.com'
* Hostname was NOT found in DNS cache
* Trying 54.231.98.120...
* Connected to xxxxxxxxxxxx.s3.amazonaws.com (54.231.98.120) port 80 (#0)
> GET /index.txt HTTP/1.1
> User-Agent: curl/7.35.0
> Host: xxxxxxxxxxxx
> Accept: */*
> Origin: http://example.com
>
< HTTP/1.1 200 OK
< x-amz-id-2: pF39K26ii42SzxSU2Dt0KT2z7+xmfyiP4yekp9s4DCYJo0jlRwCTDg6QO6f0HMIL4H9b640zq7U=
< x-amz-request-id: 3B18A563CFF4E485
< Date: Sat, 28 May 2016 21:49:21 GMT
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET
< Access-Control-Expose-Headers: Access-Control-Allow-Origin
< Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
< Cache-Control: no-cache
< Last-Modified: Sat, 28 May 2016 21:40:57 GMT
< ETag: "cd21a8c7268dc6af728d180f9a3a81d7"
< Accept-Ranges: bytes
< Content-Type: text/plain
< Content-Length: 71
* Server AmazonS3 is not blacklisted
< Server: AmazonS3
为什么这很有趣?
S3,配置有CORS和<CORSRule>
符合您的要求,始终返回CORS响应头和一个Vary:
头(意思是“如果你改变你请求中的下列其中一个标题,我可以改变一些关于我的反应。”)从标头我所指的是上面的输出,具体来说就是这些。
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Expose-Headers: Access-Control-Allow-Origin
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
我只有一个例外,那就是没有匹配的CORS规则。为了证明这一点,我首先将CORS配置更改为<AllowedOrigin>http://example.com</AllowedOrigin>
,然后重复了该请求。请注意,响应几乎是相同的,只是S3在响应中使用了确切的原点,然后加上Access-Control-Allow-Credentials
。
< Access-Control-Allow-Origin: http://example.com
< Access-Control-Allow-Methods: GET
< Access-Control-Expose-Headers: Access-Control-Allow-Origin
< Access-Control-Allow-Credentials: true
< Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
...但是,如果我-仍使用指定特定来源的限制性更强的CORS规则-然后发送的请求Origin: example.org
,这是我的CORS配置中未提及的来源,并且没有<AllowedOrigin>
匹配的通配符,则S3会做出响应好像根本没有配置CORS。
< HTTP/1.1 200 OK
< x-amz-id-2: WJ0QmIZ6jTQYefFi8GjlDQkZKFHDX8/5cmejeulhG1ov3/NdoSXbsTKetYpxvXPML8aUnPNZ/ac=
< x-amz-request-id: 15A03D8B1E08A830
< Date: Sat, 28 May 2016 21:58:34 GMT
< Cache-Control: no-cache
...etc.
这使我回到最初的结论,即您显示给浏览器的请求与为CORS配置存储桶的时间不匹配,并且可能在存储桶的CORS设置处于正确状态之前或之前已被缓存它们与您在问题中发布的内容相匹配。
如果Origin:
该请求上存在标头(如浏览器所示),那么S3应该已经添加了CORS响应标头,无论该请求是否实际上是跨域请求。
您的下一步将是在不可能被缓存的新路径上使用新对象尝试此操作,或者尝试?some-random=thing-here
在发出请求时添加到对象URL的通用浏览器缓存无效策略。失败的话,您应该考虑使用诸如此类的工具来证明或反驳正确的行为,该工具curl
可以准确地显示请求/响应中正在发生的事情。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句