Azure存储CORS返回原籍通配符,并在浏览器中失败 [英] Azure storage CORS returns origin wildcard and fails in browser

查看:250
本文介绍了Azure存储CORS返回原籍通配符,并在浏览器中失败的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在Azure上Blob存储使CORS,几乎都可以设置,但在......允许的凭据头,这始终是真实的。

因此​​,使用了原点头通配符时,pre-飞行要求正常工作和通配符转换成实际的由来。

但随后的 GET 请求不转换通配符并返回以下组合:

 访问控制允许来源:*
访问控制允许的凭据:真

这是非法的Chrome(可能其他浏览器,太)。该错误是

  XMLHtt prequest无法加载...
当凭据标志是真实的通配符*不能在使用访问控制允许来源标头。
产地:所以访问http // localhost'的是不允许的访问。

在新的WebAPI V2 CORS包通配符代替实际的起源。
另外,我为什么需要凭证,例如到Blob存储的请求饼干?更好地将其关闭。

我怎么能解决这个问题时,我想使用通配符由来?

更新

下面是初始化code我上App_Start运行

 公共静态无效初始化()
{
    // Azure的Blob存储的设置
    VAR storageAccount = CloudStorageAccount.Parse(ConfigurationManager.ConnectionStrings [AzureStorage]的ConnectionString);
    变种客户= storageAccount.CreateCloudBlobClient();
    变种serviceProperties = client.GetServiceProperties();
    serviceProperties.Cors =新CorsProperties();    serviceProperties.Cors.CorsRules.Add(新CorsRule()
    {
        AllowedHeaders =新的List<串GT;(){*},
        AllowedOrigins =新的List<串GT;(){*},
        AllowedMethods = CorsHttpMethods.Get,
        ExposedHeaders =新的List<串GT;(){*},
        MaxAgeInSeconds = 3600
    });    client.SetServiceProperties(serviceProperties);
}


解决方案

这是你遇到的错误是由于浏览器的xmlhtt preqeust为true设置withCredentials属性,在这种情况下将拒绝通配符接入控制 - 允许来源。


  

在新的WebAPI V2 CORS包通配符替换为
  实际的原点。


返回通配符是启用缓存,看看下面的情况下是正确的:


  • 用户A发送GET请求的MAS(微软Azure存储)一个公开的blob。

  • 如果您使用的是CDN /代理缓存公共资源这是一个最好的做法则CDN将缓存BLOB与访问控制允许来源设置为'*'。

  • 现在,用户B发送到MAS相同的请求,并得到从缓存中,而不是反应,因为在缓存BLOB这种情况下,具有通配符访问控制允许来源的浏览器将允许该请求,你不需要打MAS服务器。

现在在你总是返回实际原点的其他情况下,你不能缓存资源,为多个客户,因为如果访问控制允许来源有不同于实际原点的浏览器将会失败CORS请求请求原标题。


  

另外,我为什么需要凭据,如在饼干
  要求到Blob存储?更好地将其关闭。


您会因为送认证的请求的一种方式是使用Authorization头所需要的凭据,如果preflight要求不允许那么浏览器将失败,并授权头实际的请求。

When enabling CORS on Azure blob storage, almost everything can be set but the "...Allow-Credentials" header, which is always true.

So when using a wildcard for the origin-header, the pre-flight request works fine and converts the wildcard into the actual origin.

But the subsequent GET request does not convert the wildcard and returns the following combination:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

which is illegal in Chrome (and probably other browsers, too). The error is

XMLHttpRequest cannot load ...
A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true.
Origin 'http://localhost' is therefore not allowed access. 

In the new WebAPI v2 CORS package wildcards are replaced with the actual origin. Also, why would I need credentials such as cookies in a request to the blob storage? Better turn it off.

How could I fix that when I want to use the origin wildcard?

UPDATE

Here's the initialize code I run on App_Start

public static void Initialize()
{
    // Azure blob storage settings
    var storageAccount = CloudStorageAccount.Parse(ConfigurationManager.ConnectionStrings["AzureStorage"].ConnectionString);
    var client = storageAccount.CreateCloudBlobClient();
    var serviceProperties = client.GetServiceProperties();
    serviceProperties.Cors = new CorsProperties();

    serviceProperties.Cors.CorsRules.Add(new CorsRule()
    {
        AllowedHeaders = new List<string>() { "*" },
        AllowedOrigins = new List<string>() { "*" },
        AllowedMethods = CorsHttpMethods.Get,
        ExposedHeaders = new List<string>() { "*" },
        MaxAgeInSeconds = 3600
    });

    client.SetServiceProperties(serviceProperties);
}

解决方案

The error that you encountered is due to setting withCredentials property on the xmlhttpreqeust to true ,in that case the browser will reject wildcard Access-Control-Allow-Origin.

In the new WebAPI v2 CORS package wildcards are replaced with the actual origin.

Returning wildcard is the right thing to enable caching, take a look at the following scenario:

  • User A sends GET request to a public blob on MAS (Microsoft Azure Storage).
  • If you are using a CDN/Proxy to cache public resources which is a best practice then the CDN will cache the blob with Access-Control-Allow-Origin set to '*'.
  • Now User B sends the same request to MAS and gets the response from the cache instead, in that case since the cached blob has wildcard Access-Control-Allow-Origin the browser will allow that request and you don't need to hit MAS servers.

Now in the other case that you always return the actual origin, you can't cache that resources for multiple clients since the browser will fail the CORS request if the Access-Control-Allow-Origin has an actual origin that differs from request origin header.

Also, why would I need credentials such as cookies in a request to the blob storage? Better turn it off.

You would need the credentials since one way to send authenticated requests is using the Authorization header, if the preflight request doesn't allow that then the browser should fail actual requests with Authorization header.

这篇关于Azure存储CORS返回原籍通配符,并在浏览器中失败的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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