I’ve been working with a user at one of our clients who was encountering a most puzzling issue. They would be logged into one of our applications, and then they would invoke some functionality that was hosted off of another subdomain. Cookies in the browser that are shared by the two sub-domains were supposed to allow the user to access both apps, but when they would open the window to the other subdomain, they would receive an authentication error.
The engineering team spent a while looking at it, but everything appeared to be happening correctly, so they asked me to lend a hand and see if I could puzzle out what was happening.
After gathering some data using HttpWatch from the end user, I could see that when they reached the other domain, the browser was simply not sending the cookies. The main application had the cookies set correctly (e.g. mainapp.mydomain.com had a cookie set for “.mydomain.com”), but when they switched over to the second site (e.g. sideapp.mydomain.com), the browser was simply refusing to send the cookie, even though the domain was correct.
We couldn’t reproduce the issue on our side, and I even watched the user demonstrate the problem live over a webex. It worked fine for other browsers like Chrome, but in IE8 it was consistent – the requests to the second domain just didn’t include the domain-wide cookies originally set by the first subdomain. The cookies were being properly set to be shared across the whole domain, but on this user’s machine, they just wouldn’t be sent for the second site.
After multiple sessions with the client, we finally discovered that the problem was related to IE’s trusted sites functionality. The first site was set in the user’s trusted site list, but the second site was not.
As I finally found in an article on MSDN:
For security reasons, each Integrity level maintains its own isolated cookie store. This is problematic when two servers expect to share cookies but cannot because they are running at different Integrity levels.
Once the browser shifted from one subdomain to another, it was using a different storage system for the cookies. Even though the cookies were set to properly be shared, IE was refusing to do so.
If both domains were trusted, or if both domains were untrusted, the user would have been fine. The cookies would be in the same security zone, and Internet Explorer would send them to both subdomains as it was supposed to. However, once the trust zones were mixed, we ran into issues.
Once the user added the second site to their trusted site list, it started working properly.
On a side note, this functionality seems to be at least partially tied to IE’s new process model introduced in IE8, where different tabs or windows may be served by different processes with session merging underneath to share cookies. When we used the registry entry to force IE back into the single process model used by IE7, the browser sent the proper cookies to both sites despite the separate security zones. However, we needed to understand why the problem was occurring in the standard multi-process model, so we couldn’t use this as our solution. Eventually, we found the trusted site problem.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
