Google Storage的CORS政策从我的来源开始就允许使用,但是没有"Access-Control-Allow-Origin"标头存在 [英] CORS policy with Google Storage allows from my origin, but no 'Access-Control-Allow-Origin' header is present

查看:129
本文介绍了Google Storage的CORS政策从我的来源开始就允许使用,但是没有"Access-Control-Allow-Origin"标头存在的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是CORS配置的新手,正在尝试弄清楚这一点,但是根据文档,我的设置似乎是正确的.我希望你能帮助我看看我错过了什么.我的代码正在尝试使用签名的URL直接将文件上传(PUT)到Google存储设备.

I'm new to CORS configuration and trying to figure this out, but my set up looks like it is right according to the documentation. I'm hoping you can help me see what I've missed. My code is trying to upload (PUT) a file directly to google storage using a signed url.

在以下位置访问XMLHttpRequest ' https://storage.googleapis.com/herdboss-dev.appspot.com/uploads/152/152-owner-152-61.jpg?X-Goog-Algorithm=GOOG4 -RSA-SHA256& X-Go ..." 来源" https://herdboss-dev.appspot.com 被阻止 CORS政策: 请求的资源.

Access to XMLHttpRequest at 'https://storage.googleapis.com/herdboss-dev.appspot.com/uploads/152/152-owner-152-61.jpg?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Go...' from origin 'https://herdboss-dev.appspot.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

我已在Google存储桶上设置了CORS策略(增加了换行符,以提高可读性):

I've set the CORS policy on my Google Storage Bucket (added line breaks for readability):

% gsutil cors get gs://herdboss-dev.appspot.com               
[{
"maxAgeSeconds": 3600, 
"method": ["GET", "HEAD", "PUT"], 
"origin": ["https://herdboss-dev.appspot.com"], 
"responseHeader": ["X-Requested-With", "Access-Control-Allow-Origin", "Content-Type"]
}]

根据我的Chrome检查器,发生飞行前请求并返回正确的方法和标头(据我所知).另外,作为一个旁注,我注意到PUT在OPTIONS之前出现在我的Chrome检查器中,但是时间戳显示OPTIONS首先发送.

According to my chrome inspector, the pre-flight request happens and returns the proper methods and headers (as far as I can tell). Also, as a side note, I noticed the PUT shows up in my Chrome inspector before the OPTIONS, but the timestamps show the OPTIONS is sent first.

OPTIONS调用发生时,Google Storage正确响应并说它可以支持我的请求方法GET, HEAD, PUT和来源https://herdboss-dev.appspot.com:

When the OPTIONS call happens, Google Storage correctly responds and says it can support my request methods GET, HEAD, PUT and origin https://herdboss-dev.appspot.com:

所请求的内容

但是,当PUT发生时,Google存储空间不会使用正确的Access-Control-Allow-Origin标头进行响应:

However, when the PUT happens, Google Storage does not respond with the proper Access-Control-Allow-Origin header:

我缺少什么或做错了什么?当我直接进行http调用时,可以将这些签名的url直接用于​​PUT文件到我的Google存储桶中,因此我知道签名的url可以工作.我刚遇到这个CORS问题.对我来说这是新事物,我以前从未处理过,但似乎我正在设置所有我应该设置的东西.

What am I missing or doing wrong? I'm able to use these signed urls to PUT files directly into my Google Storage bucket when I make a direct http call, so I know the signed urls work. I'm just running into this CORS problem. It's a new thing for me, I haven't dealt with it before, but it seems like I'm setting all of the things I should be setting.

**

我尝试将我的允许原点设置为*,就像测试一样,但我仍然被相同的No 'Access-Control-Allow-Origin' header is present on the requested resource.拒绝.Chrome检查器显示OPTIONS响应确实发回了我的*以允许原点,但是仍然没有用,并且仍然给出了相同的错误.

I tried setting my allowed origins to * just as a test and I was still rejected with the same No 'Access-Control-Allow-Origin' header is present on the requested resource. The Chrome inspector showed the OPTIONS response did send back my * for allowed origins, but it still didn't work and still gave the same error.

推荐答案

弄清楚了.

简短版本:Chrome关于CORS的错误消息是一条红色鲱鱼. Google存储拒绝了被解释为违反CORS的请求.

Short version: Chrome's error message about CORS was a red herring. Google Storage was rejecting the request which was being interpreted as a CORS violation.

长版:

我在Chrome的检查器中注意到,对我的PUT请求的响应的内容长度为862个字符,但Chrome并未显示任何响应.我打开Firefox并再次尝试了上传过程,但失败了,并显示了有关CORS和Access-Control-Allow-Origin的相同错误消息.但是,在Firefox的网络检查器中,我能够看到原始响应正文!

I noticed in Chrome's inspector that the response to my PUT request had a content length of 862 characters, but Chrome wasn't showing me any response. I opened Firefox and tried the upload process again and it failed with the same error messages about CORS and Access-Control-Allow-Origin. However, in Firefox's network inspector, I was able to see the raw response body!

<Error>
    <Code>SignatureDoesNotMatch</Code>
    <Message>The request signature we calculated does not match the signature you provided. Check your Google secret key and signing method.</Message>
    <StringToSign>.....</StringToSign>
    <CanonicalRequest>PUT
/herdboss-dev.appspot.com/uploads/152/152-owner-152-72.png
X-Goog-Algorithm=GOOG4-RSA-SHA256&amp;....;X-Goog-SignedHeaders=content-type%3Bhost
content-type:image/png
host:storage.googleapis.com

content-type;host
UNSIGNED-PAYLOAD
    </CanonicalRequest>
</Error>

我的理论是,当Chrome和Firefox进行飞行前CORS检查,然后发出PUT请求并收到403响应代码时,即使该问题与CORS无关,它仍在响应,好像是CORS问题一样,并且飞行前响应DID实际上具有Access-Control-Allow-Origin标头.

My theory is that when Chrome and Firefox do the pre-flight CORS checking and then issue the PUT request and receive a 403 response code that it is responding as if it is a CORS problem even though the problem was not CORS related and the preflight response DID actually have the Access-Control-Allow-Origin header.

从这里,我可以通过针对请求检查我的url签名代码来快速诊断问题.我注意到,当创建签名的上传URL时,我需要Content-typeapplication/octet-stream,但是当浏览器中的javascript执行PUT请求时,它会将Content-type设置为image/png.我更新了JavaScript,以强制Content-typeapplication/octet-stream匹配,然后请求成功.

From here, I was able to quickly diagnose the problem by checking my url signing code against the request. I noticed that when created the signed upload url that I was requiring a Content-type of application/octet-stream but when the javascript in the browser was doing the PUT request that it was setting the Content-type to image/png. I updated my javascript to force the Content-type to match application/octet-stream and then the request succeeded.

这篇关于Google Storage的CORS政策从我的来源开始就允许使用,但是没有"Access-Control-Allow-Origin"标头存在的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆