代码之家  ›  专栏  ›  技术社区  ›  Michael Lorton

CloudFront未正确地从S3传回访问控制允许源站标头

  •  0
  • Michael Lorton  · 技术社区  · 4 年前

    我从两个不同的域访问CloudFront。我将S3配置为允许来自两个域的跨源。来自mydomain1的页面将正确获取数据,然后来自mydomain2的页面将正确发送请求:

    > origin: https://mydomain2
    

    CloudFront的回应是:

    < content-type: application/json
    < content-length: 65
    < date: Fri, 04 Dec 2020 22:45:50 GMT
    < access-control-allow-origin: https://mydomain1
    < access-control-allow-methods: GET, PUT
    < access-control-allow-credentials: true
    < accept-ranges: bytes
    < server: AmazonS3
    < x-cache: Hit from cloudfront
    

    当然,浏览器阻止了这个请求,因为允许的来源不匹配

    我最初认为我的源代码请求策略是错误的,但没有,我使用的是Managed-CORS-S3Origin,它有正确的源代码 名称 我检查了它,它说它正在将源代码头传递给S3源代码——由于内容分发业务中的“源代码”与HTTP业务中的“源代码”含义非常不同,所以问题并没有变得更容易。

    但很明显,访问控制Allow Origin response标头的值 因为某种原因被缓存。

    1 回复  |  直到 4 年前
        1
  •  22
  •   Michael Lorton    4 年前

    因为AWS的人想杀我,所以CloudFront缓存有两种不同的策略。

    一个是源请求策略,它控制从CloudFront传递到S3的头。它被自动正确地设置为传递到原始标题。

    另一个是缓存策略,它选择用于形成缓存键的头,在本例中不包括源。

    这就是 简直疯了 缓存密钥是指类似CDN的CloudFront如何确定两个请求足够相似,从而可以将对第一个请求的响应重放为对第二个请求的响应。

    好吧,也许有 一些 系统需要一个报头,但不关心值,因此CloudFront应该在第一个请求中传递报头,然后缓存响应以满足后续每个请求,而不管报头是什么。

    但是 在99.9%的时间里,服务器需要报头,因为它将使用报头的值来创建响应,而不同的报头值将引发不同的响应。当然,S3和Origin报头就是这样,因为S3将Origin请求报头的值复制到响应的Access Control Allow Origin报头中。

    因此,如果您选择Managed-CORS-S3Origin请求策略来管理具有S3源的cor,那么CORS在您编写匹配的缓存策略之前将无法工作。没人告诉你这些。哦!

    Auuuggghhh