image - Canvas 被 CORS 数据和 S3 污染

Question

我的应用程序显示存储在 中的图像AWS S3 (出于安全原因，在私有(private)存储桶中)。

为了让用户从他们的浏览器中看到图像，我生成了 签名 URL 喜欢 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>

和 img.crossOrigin = ""或 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 端和/或客户端配置？

Answer 1

这里的一种解决方法是防止浏览器缓存下载的对象。这似乎源于 S3 与 Chrome 处理缓存对象的方式交互的部分可以说是不正确的行为。我最近回答 a similar question on Server Fault ，您可以在那里找到更多详细信息。

当您从简单的 HTML(如 <img> 标签)中从 S3 获取一个对象，然后在跨域上下文中再次获取相同的对象时，问题似乎出现了。

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

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

Web 服务器(在本例中为 S3)可以使用 Vary:响应 header 向浏览器发出信号，表明服务器能够生成不止一种返回对象的表示——以及浏览器是否会变化 请求的一个属性，响应 可能不同。当浏览器考虑使用缓存对象时，它应该检查该对象在新上下文中是否有效，然后才能得出缓存对象适合当前需求的结论。

确实，当您发送 Origin 时向 S3 发送请求 header ，您会得到包含 Vary: Origin 的响应.这告诉浏览器如果请求中发送的来源是不同的值，响应也可能不同——例如，因为并非所有来源都被允许。

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

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

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

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

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

或者，如果您可以在呈现页面时为同一对象分别生成这两个签名 URL，只需更改一个签名 URL 相对于另一个的过期时间。让它多一分钟，或者类似的东西。将过期时间从一个更改为另一个将强制两个签名的 URL 不同，具有两个不同查询字符串的两个不同对象应该被 Chrome 解释为两个单独的对象，这也应该消除第一个缓存对象的错误使用为另一个请求服务。