Question

经过我们在Azure中作为Web角色托管的开发/测试环境的大量调试后，突然停止使用Chrome 34，我们发现Chrome忽略了具有域名cookie的设置cookie响应＆＃34; .cloudapp.net＆＃34; （Azure中云服务的默认公共Microsoft域）。我们选择此名称的原因是能够在不同的云服务之间生成CORS请求，这些请求需要来自同一javascript应用程序的安全请求。这意味着从http://example.cloudapp.net等MVC站点获取身份验证cookie，并在http://exampleServices.cloudapp.net等其他Web角色中调用安全WebApi REST服务（仅适用于具有相同域名的cookie）

以下是生成身份验证cookie的云服务的身份验证响应示例：

Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Origin:http://example.cloudapp.net
Cache-Control:private
Content-Length:31
Content-Type:application/json; charset=utf-8
Date:Fri, 11 Apr 2014 20:21:20 GMT
Server:Microsoft-IIS/8.0
Set-Cookie:.COOKIENAME=XXXXXXXXXXXXXXXXXXXX; domain=.cloudapp.net; path=/; HttpOnly

我们遇到的问题是，Chrome34在此域名中放弃了Cookie，因此任何其他请求都未经过身份验证。我们可以购买公共域并在azure中设置我们的云服务，但我想知道是否有任何解决此问题的方法。

Answer 1

这可能是因为Chrome等浏览器使用公开后缀列表（https://publicsuffix.org/list/effective_tld_names.dat）来限制某些Cookie。如果在cookie上设置的域后缀是公开共享的，则浏览器可以阻止这样的cookie，以防止自己将“未授权”数据发送到在同一域上运行的其他服务器。请注意，cloudapp.net域位于Public Suffix列表中。

Chrome34忽略了域名＆＃34; .cloudapp.net＆＃34;

1 个答案: