问题
After a lot of debugging from our dev/test environments hosted as web roles in Azure, that suddenly stopped working with Chrome 34, we realize that Chrome was ignoring the set-cookie response that has cookies with domain name ".cloudapp.net" (the default public Microsoft domain for cloud services in Azure). The reason we choose this name was to be able to generate CORS requests among different cloud services that needed secure requests from the same javascript App. This means getting an authentication cookie from a MVC site like http://example.cloudapp.net and calling secure WebApi REST services in another web role like http://exampleServices.cloudapp.net (only works with cookies with the same domain name)
The following is an example of the authentication response from the cloud service that generates the authentication 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
The problem we are facing is that the cookie is discarted in Chrome34 with this domain name, so any other request is not authenticated. We can buy a public domain and setup our cloud services in azure, but I'd like to know if there is any work around to this problem.
回答1:
This is probably because browsers like Chrome use the Public Suffix List(https://publicsuffix.org/list/effective_tld_names.dat) to restrict certain cookies. If the domain suffix set on the cookie is shared publicly then the browser may block such a cookie in order to prevent itself from sending "unauthorized" data to other servers running on the same domain. Note that cloudapp.net domain is there in the Public Suffix list.
来源：https://stackoverflow.com/questions/23024351/chrome34-ignores-cookies-with-domain-cloudapp-net