画布被 CORS 数据和 S3 污染

我的应用程序正在显示存储在AWS S3（出于安全原因，位于私人存储桶中）。

为了允许用户从浏览器中查看我生成的图像签名 URL like https://s3.eu-central-1.amazonaws.com/my.bucket/stuff/images/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=...&X-Amz-Date=20170701T195504Z&X-Amz-Expires=900&X-Amz-Signature=bbe277...3358e8&X-Amz-SignedHeaders=host.
这与完美配合<img src="S3URL" />：图像正确显示。
我什至可以通过复制/粘贴 URL 来直接查看另一个选项卡中的图像。

我还生成嵌入这些图像的 PDF，这些图像之前需要使用canvas：调整大小并加水印。

但我用于调整大小的库遇到了一些麻烦：

Failed to execute 'getImageData' on 'CanvasRenderingContext2D':
The canvas has been tainted by cross-origin data.

事实上我们正处于一个CORS上下文，但我已经设置了所有内容，以便可以将图像显示给用户，并且确实可以正常工作。
所以我不确定理解这个错误的原因：这是另一个 CORS 安全层吗：浏览器担心我可能出于恶意目的更改图像？

我尝试设置一个宽松的CORS配置在 S3 存储桶上：

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

And img.crossOrigin = "" or img.crossOrigin = "Anonymous"在客户端，但随后我得到：

Access to Image at 'https://s3.eu-central-1.amazonaws.com/...'
from origin 'http://localhost:5000' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://localhost:5000' is therefore not allowed access.

可能缺少哪些 AWS/S3 端和/或客户端配置？

这里的一种解决方法是阻止浏览器缓存下载的对象。这似乎源于 S3 与 Chrome 处理缓存对象的方式交互的不正确行为。我最近回答过关于服务器故障的类似问题，您可以在那里找到更多详细信息。

当您从简单的 HTML（例如<img>tag），然后在跨域上下文中再次获取相同的对象。

Chrome 会缓存第一个请求的结果，然后使用缓存的响应，而不是在第二次发出新请求。当它检查缓存的对象时，没有Access-Control-Allow-Origin标头，因为它是从不受 CORS 规则约束的请求中缓存的...因此，当发出第一个请求时，浏览器不会发送Origin标头。因此，S3 没有回复Access-Control-Allow-Origin标头（或任何与 CORS 相关的标头）。

问题的根源似乎与 HTTP 有关Vary:响应头，与缓存相关。

Web 服务器（本例中为 S3）可以使用Vary:响应头向浏览器发出信号，表明服务器能够生成返回对象的多种表示形式——以及浏览器是否愿意vary请求、响应的属性might不同。当浏览器考虑使用缓存对象时，它应该检查该对象在新上下文中是否有效，然后再得出缓存对象适合当前需要的结论。

事实上，当您发送Origin向 S3 请求标头，您会得到一个响应，其中包括Vary: Origin。这告诉浏览器，如果请求中发送的源是不同的值，则响应也可能不同——例如，因为并非所有源都被允许。

根本问题的第一部分是 S3——可以说——应该always return Vary: Origin每当在存储桶上配置 CORS 时，即使浏览器没有发送原始标头，因为Vary可以针对您实际未包含在请求中的标头指定，以告诉您如果包含它，响应可能会有所不同。但是，当Origin不存在。

问题的第二部分是 Chrome——当它查询其内部缓存时——发现它已经拥有该对象的副本。播种缓存的响应不包括Vary，因此 Chrome 假定该对象对于 CORS 请求也完全有效。显然，事实并非如此，因为当 Chrome 尝试使用该对象时，它发现跨域响应标头丢失。据推测，Chrome 是否收到了Vary: OriginS3 对原始请求的响应，它会意识到第二个请求的临时请求标头包括Origin:，因此它会正确地获取对象的不同副本。如果这样做了，问题就会消失——正如我们通过设置所说明的那样Cache-Control: no-cache对象上，阻止 Chrome 缓存它。但是，事实并非如此。

因此，我们通过设置来解决这个问题Cache-Control: no-cache在 S3 中的对象上，这样 Chrome 就不会缓存第一个对象，而是为第二个对象发出正确的 CORS 请求，而不是尝试使用缓存的副本，这会失败。

请注意，如果您想避免更新 S3 中的对象以包含Cache-Control: no-cache响应，还有另一种选择可以解决此问题，而无需实际将标头添加到 S3 中的静态对象。实际上，还有两个选择：

S3 API 尊重在查询字符串中传递的值response-cache-control=no-cache。将其添加到签名 URL 将指示 S3 将标头添加到响应中，无论Cache-Control与对象一起存储的元数据值（或缺少）。您不能简单地将其附加到查询字符串中——您必须将其添加为 URL 签名过程的一部分。但是一旦将其添加到代码中，您的对象将返回Cache-Control: no-cache在响应标头中。

或者，如果您可以在呈现页面时分别为同一对象生成这两个签名 URL，则只需更改其中一个签名 URL 相对于另一个签名 URL 的过期时间即可。延长一分钟，或者类似的事情。将过期时间从一个更改为另一个将强制两个签名 URL 不同，并且具有两个不同查询字符串的两个不同对象应被 Chrome 解释为两个单独的对象，这也应该消除第一个缓存对象的错误使用以满足其他请求。