Tag Archives: Internet Explorer

ASP.NET 4.0 forms authentication issues with IE11

As I mentioned earlier, solutions that rely on User-Agent sniffing may break, when a new browser or a new version of an existing browser is released. Unfortunately because ASP.NET also contains browser-specific code, the new Internet Explorer 11 may cause some problems there as well.

Lucky coincidence, that one day after my previous post Eric Lawrence published an article about IE11 and User-Agent sniffing. Some interesting facts from his article:

  • The IE team deliberately designed the UA string to cause most sniffing logic to interpret it either Gecko or WebKit and not as previous IE version.
  • During the summer the ASP.NET team published a set of patches to fix the IE11 issues in earlier .NET versions. For example KB2836939 is for .NET 4.0, and you can find more links in Eric’s article.

The issue we experienced was on an older server that was running ASP.NET 4.0. IE11 sent the forms authentication cookie to the server, but the server completely ignored it. In the web.config file the forms element didn’t contain the cookieless attribute, because the default UseDeviceProfile worked perfectly before, however now we had to set it to UseCookies to make the authentication work with IE11 as well.

The patch mentioned earlier was not installed on this server, and we have not seen similar issues on .NET 4.5.

By the way setting cookieless="UseCookies" explicitly is a good security practice.


Technorati-címkék: ,,,

IE11 User-Agent string

Windows 8.1 comes with the new Internet Explorer 11 which sends the following User-Agent string in the HTTP requests to the webservers:

Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

To see what’s the point here, compare this with the old versions’ UA strings:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

The format completely changed, what’s more the MSIE token is completely removed! This change may cause issues, if your code contains browser-specific parts, because your old code probably won’t recognize the new browser.

Even the ASP.NET platform contains codes which respect the client’s browser, and unfortunately there were some issues in the past when some features didn’t work well with the new browsers.

Thankfully the browser detection feature of ASP.NET is completely customizable with .browser files, and if you check the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Browsers\ie.browser file on Windows 8.1, you will see that it already contains a section for IE11:

<browser id="InternetExplorer" parentID="Mozilla">
     <userAgent match="Trident/(?'layoutVersion'[7-9]|0*[1-9]\d+)(\.\d+)?;(.*;)?\s*rv:(?'version'(?'major'\d+)(\.(?'minor'\d+)))" />
     <userAgent nonMatch="IEMobile" />
     <userAgent nonMatch="MSIE " />
     <capability name="browser"              value="InternetExplorer" />
     <capability name="version"              value="${version}" />
     <capability name="majorversion"         value="${major}" />
     <capability name="minorversion"         value="${minor}" />
     <capability name="layoutEngine"         value="Trident" />
     <capability name="layoutEngineVersion"  value="${layoutVersion}" />
     <capability name="type"                 value="InternetExplorer${major}" />

My personal experience is that old web applications must be thoroughly tested with the new IE11, even if you didn’t write any browser-dependent code, because the platform you rely on may also contain such logic. You must be especially careful if you run ASP.NET 4.0 on the server (probably because you cannot do the in-place upgrade to 4.5).

In a next post I will write about some issues we saw while we tested our ASP.NET apps with IE11.


Technorati-címkék: ,,

Use Outlook Web App in full version with IE 11

If you upgraded to Windows 8.1 and tried to access Outlook Web App with the new Internet Explorer 11, you probably noticed that the “Use the light version of Outlook Web App” checkbox is checked and disabled on the login page:


That means that IE11 is willing to render only the basic version of OWA which was originally designed to target legacy browsers. This is quite embarassing, because IE11 is a really modern browser even in the preview!

The solution is to force IE to render OWA in compatibility mode. You can add the site to the compatibility list in the Tools –> Compatibility View Settings dialog:


This didn’t solve my problem, because only top-level domains can be added to this list, but I could took the advantage of the fact that according to the first checkbox, intranet sites are by default rendered in compatibility view. So I added my OWA URL to the list of sites in the Intranet Zone in the Tools –> Internet Options –> Security –> Local intranet –> Sites –> Advanced dialog.

According to some forum posts, the same issue arises with Office 365 and some popular websites like GitHub as well.


Technorati-címkék: ,,