This was my first taste of presenting at a big name developer conference, and what a great event it turned out to be. If you attended my talk on Yammer API Development I hope you found it worthwhile. Please @mention me on the Yammer Developer Network with any follow-up questions.
There were some awesome from Elijah Manor, Bill Wagner, and many others. Co-locating the conference alongside Angle Brackets and the other Intersection conferences allowed me to dip into relevant talks from a range of speakers I normally wouldn't be able to see.
If you are interested in more of this, the next one will be held in Orlando in April.
Internet Explorer has quite a complex security model compared to other browsers. One unique feature is the infamous Security Zone. Zones apply different policies to code based on the URL. By default, you have the following zones: Internet, Local Intranet, Trusted Sites, Restricted Sites, and My Computer.
Each of these zones has a slightly different configuration depending on the intended usage. For example, the Internet zone is designed to handle untrusted code from the internet. The settings are locked down tightly, and recent versions of IE run this code in a sandbox with Protected Mode.
Compare this to the Intranet zone which has a more relaxed configuration. If a URL is included in this zone it is considered to be trusted to a greater degree than one in the Internet zone. IE will even respond differently to authentication requests for sites in the Intranet zone to support Windows Authentication (see IWA, NTLM, Kerberos, and SPEGNO.)
Everything is fine and dandy when your application has code that only loads from URLs belonging to a single zone. However, things will start to go pear-shaped when you have code loading from different zones. The exact behaviour will depend on your application, but you'll often see inconsistent behaviour between environments. The explanation for this is often the application of group policy resulting in different connfigurations across machines.
So how do you go about debugging these issues? My approach is to start with the following:
Make sure the problem only happens in IE. Doing this will save you a lot of pain as debugging with the Chrome developer tools is often a more pleasant experience than using the IE tools.
Identify all of the domains hosting your code. Understand what zones contain your host page, and which ones contain other scripts or code that you are pulling in.
Temporarily move all of the code into a single zone. If you move all of your code into a single zone for testing you can confirm whether Protected Mode issues are at the heart of your problem. You may need to tweak some IE zone settings to get the features you need, but it's a good start.
Disable compatibility view. Sites in the Intranet zone use this feature by default, and it can cause problems. Temporarily turn it completely off for the Intranet Zone so that that things are consistent across zones.
Use IE Zone Analyzer. This tool allows you to review the configuration of zones in great detail, and help with bugs that only appear in certain environments. It is available for free from Microsoft.
At this point you'll be in a better position to debug specific code in IE, but how do you remediate the problem? Well you have to make a change somewhere. It is common for admins to add wildcards like *.domain.com to the Intranet zone. Naturally this will not discriminate between Intranet sites, and cause a lot of problems if you have modern code that doesn't run well under Compatibility View. Try to educate your admins on the appropriate configuration so that your environment will be more secure, and you'll also spend less time debugging!
Expat Coder
