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.
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…