Cloudfront使用签名的URL来获取S3对象的间歇性403 CORS错误（访问控制允许起源） [英] Intermittent 403 CORS Errors (Access-Control-Allow-Origin) With Cloudfront Using Signed URLs To GET S3 Objects

问题描述

简介

为使多租户系统上所有客户端的上载媒体（S3对象）保持私有状态，我实施了Cloudfront CDN部署并进行了配置它（及其Origin S3存储桶）强制使用签名的URL来获取任何对象。

方法

首先，用户是通过我的系统进行身份验证，然后使用

此错误（错误）已在所有环境中得到确认：localhost，dev.myapp。 com，prod.myapp.com。在所有平台/浏览器中。

由于缺乏韵律或原因，我实际上开始认为这是一个AWS错误（确实发生了，有时）。

到目前为止的调试清单

数天以来我一直在想着要解决这个问题。到目前为止，这是我尝试过的操作：

您是否尝试过其他浏览器/平台？

是。该问题存在于所有客户端来源，浏览器（和
版本）以及所有平台上。

您的S3存储桶是否正确配置了CORS？

是。实际上，它是开放的。我什至在
中设置了< MaxAgeSeconds> 0< / MaxAgeSeconds> ，以防止缓存任何飞行前 OPTIONS 客户端的code>请求：

签名的URL是否已过期？

不是。所有签名的URL都设置为在生成后24小时过期。生成任何给定的签名URL后，甚至在秒
中都显示了此问题。

用于生成签名URL的方法是否存在问题？

不太可能。我只是使用其JS SDK的 AWS.CloudFront.Signer.getSignedUrl（）
方法。签名的URL do 大部分时间都在工作，因此
看起来很奇怪，因为签名
会带来问题。同样，该错误显然是CORS错误，而不是签名
不匹配错误。

是时区/服务器时钟问题吗？

不。该系统确实为多个时区的用户提供服务，但是
理论被证明是错误的，因为签名的URL都是在服务器端生成的
。客户端的时区无关紧要，无论生成的是什么
TZ，它都会从生成之时起24小时获得
a签名URL。

您的CF发行版是否配置正确？

是的，据我所知通过遵循几个

由于
实现的特殊性，您显然无法从HTML成功获取对象，然后
作为Chrome和S3
（带有或不带有CloudFront）的CORS请求成功地再次获取了对象。

从原始帖子中添加答案，以免丢失。

解决方法：

可以使用CloudFront和Lambda解决此问题。 @Edge，使用以下代码作为原始响应触发器。

这会增加Vary：Access-Control-Request-Headers，Access-Control-Request-Method，Origin来自S3且没有Vary标头的任何响应。否则，响应中的Vary标头将不会被修改。

 使用严格； 
 
 //如果响应缺少Vary：标头，请在CloudFront Origin Response触发器中修复它。 
 
exports.handler =（事件，上下文，回调）=> {
 const response = event.Records [0] .cf.response; 
 const headers = response.headers; 
 
 if（！headers ['vary']）
 {
 headers ['vary'] = [
 {键：'Vary'，值：'Access -Control-Request-Headers'}，
 {键：'Vary'，值：'Access-Control-Request-Method'}，
 {键：'Vary'，值：'Origin'} ，
]; 
} 
回调（空，响应）； 
}; 
  

In Brief

In order to keep the uploaded media (S3 objects) private for all the clients on my multi-tenant system I implemented a Cloudfront CDN deployment and configured it (and its Origin S3 Bucket) to force the use of signed URLs in order to GET any of the objects.

The Method

First, the user is authenticated via my system, and then a signed URL is generated and returned to them using the AWS.CloudFront.Signer.getSignedUrl() method provided by the AWS JS SDK. so they can make the call to CF/S3 to download the object (image, PDF, docx, etc). Pretty standard stuff.

The Problem

The above method works 95% of the time. The user obtains a signed URL from my system and then when they make an XHR to GET the object it's retrieved just fine.

But, 5% of the time a 403 is thrown with a CORS error stating that the client origin is not allowed by Access-Control-Allow-Origin.

This bug (error) has been confirmed across all environments: localhost, dev.myapp.com, prod.myapp.com. And across all platforms/browsers.

There's such a lack of rhyme or reason to it that I'm actually starting to think this is an AWS bug (they do happen, from time-to-time).

The Debugging Checklist So Far

I've been going out of my mind for days now trying to figure this out. Here's what I've attempted so far:

Have you tried a different browser/platform?

Yes. The issue is present across all client origins, browsers (and versions), and all platforms.

Is your S3 Bucket configured for CORS correctly?

Yes. It's wide-open in fact. I've even set <MaxAgeSeconds>0</MaxAgeSeconds> in order to prevent cacheing of any pre-flight OPTIONS requests by the client:

Is the signed URL expired?

Nope. All of the signed URLs are set to expire 24hrs after generation. This problem has shown up even seconds after any given signed URL is generated.

Is there an issue with the method used to generate the signed URLs?

Unlikely. I'm simply using the AWS.CloudFront.Signer.getSignedUrl() method of their JS SDK. The signed URLs do work most of the time, so it would seem very strange that it would be an issue with the signing process. Also, the error is clearly a CORS error, not a signature mis-match error.

Is it a timezone/server clock issue?

Nope. The system does serve users across many timezones, but that theory proved to be false given that the signed URLs are all generated on the server-side. The timezone of the client doesn't matter, it gets a signed URL good for 24hrs from the time of generation no matter what TZ it's in.

Is your CF distro configured properly?

Yes, so far as I can make out by following several AWS guides, tutorials, docs and such.

Here's a screenshot for brevity. You can see that I've disabled cacheing entirely in an attempt to rule that out as a cause:

Are you seeing this error for all mime-types?

No. This error hasn't been seen for any images, audio, or video files (objects). With much testing already done, this error only seems to show up when attempting to GET a document or PDF file (.doc, .docx, .pdf). This lead me to believe that this was simply an Accept header mis-match error: The client was sending an XHR with the the header Accept: pdf, but really the signature was generated for Accept: application/pdf. I haven't yet been able to fully rule this out as a cause. But it's highly unlikely given that the errors are intermittent. So if it were a Accept header mis-match problem then it should be an error every time.

Also, the XHR is sending Accept: */* so it's highly unlikely this is where the issue is.

The Question

I've really hit a wall on this one. Can anyone see what I'm missing here? The best I can come up with is that this is some sort of "timing" issue. What sort of timing issue, or if it even is a timing issue, I've yet to figure out.

Thanks in advance for any help.

解决方案

Found the solution for the same on serverfault.

https://serverfault.com/questions/856904/chrome-s3-cloudfront-no-access-control-allow-origin-header-on-initial-xhr-req

You apparently cannot successfully fetch an object from HTML and then successfully fetch it again with as a CORS request with Chrome and S3 (with or without CloudFront), due to peculiarities in the implementations.

Adding the answer from original post so that it does not get lost.

Workaround:

This behavior can be worked-around with CloudFront and Lambda@Edge, using the following code as an Origin Response trigger.

This adds Vary: Access-Control-Request-Headers, Access-Control-Request-Method, Origin to any response from S3 that has no Vary header. Otherwise, the Vary header in the response is not modified.

'use strict';

// If the response lacks a Vary: header, fix it in a CloudFront Origin Response trigger.

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;
    const headers = response.headers;

    if (!headers['vary'])
    {
        headers['vary'] = [
            { key: 'Vary', value: 'Access-Control-Request-Headers' },
            { key: 'Vary', value: 'Access-Control-Request-Method' },
            { key: 'Vary', value: 'Origin' },
        ];
    }
    callback(null, response);
};

这篇关于Cloudfront使用签名的URL来获取S3对象的间歇性403 CORS错误（访问控制允许起源）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！