91

Summary

ASP.Net does not send back a Set-Cookie header when using IE 10. Meaning that for example you cannot login to an ASP.Net site using IE10 when using Forms Authentication for example.

Detail

We're currently testing one of our legacy web apps against IE 10 [Preview 2].

When attempting to login using Forms Authentication, we don't get a Set-Cookie header in the response if the user-agent is that of IE 10. We've tried this with a blank .Net 2 and .Net 4 site.

Because we couldn't/wouldn't believe it, we even ran the follow HTTP request manually through telnet - after using all usual tools - and got the same response.

GET http://test.ourdomain.co.uk/ HTTP/1.1
Accept: */*
Host: test.ourdomain.co.uk
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)
Content-Length: 0

The above HTTP request returns no Set-Cookie in the response. Yet if we simply change the User-Agent to Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/6.0) it works!

Can anyone else replicate this? I can't find any known issue with IE10 cookies other than an issue that effects non-standard URL patterns.

Hotfix

After devio posted the original answer, with a workaround, nullptr has confirm that there is now a hotfix for this.

http://support.microsoft.com/kb/2600088

I've promoted the hotfix to the main question as it's just handier for future reference, but please do up-vote the users mentioned.

Community
  • 1
  • 1
isNaN1247
  • 17,793
  • 12
  • 71
  • 118

6 Answers6

71

The problem rests with some IIS instances thinking that IE10 is a cookieless browser (i.e. cant support cookies). In our problem case the server was setting the authentication cookie and sending it back to the browser, but was then ignoring the cookie on subsequent requests.

The solution is to either patch the browser capabilities so that it knows IE10 can do cookies (outlined in another answer on this page), or change the default behaviour to force it to use cookies even if it thinks the browser can’t do cookies.

We just added the following to our forms section in web.config:

cookieless="UseCookies"

<authentication mode="Forms">
  <forms name=".AUTH" cookieless="UseCookies" loginUrl="/" timeout="10000" path="/" />
</authentication>
Dave Sumter
  • 2,926
  • 1
  • 21
  • 29
  • 3
    that fixed our issue with IE10 – Oleg Yevteyev Mar 28 '13 at 17:42
  • 1
    After trying the other solutions, and the hotfix refusing to install saying it wasn't compatible with our server, I tried this. It's the only thing that fixed the issue for us. – Brian Surowiec May 16 '13 at 22:17
  • All I had to do was tweak Web.config to see immediate results. Bravo – tuespetre Jul 03 '13 at 18:44
  • I think this is the correct answer. The cookie was being set so everything looked fine in fiddler and ASP.NET was able to read it back perfectly fine (when I set up a test page) but Forms Auth was ignoring it. This is a serious limitation of Forms Auth but your fix makes it work like it always should have! – mike nelson Jul 21 '13 at 23:42
  • 1
    This is a far better and tenable solution from patching IIS. – generalnetworkerror Jul 27 '13 at 02:32
  • Agreed with @generalnetworkerror. In my case, I can easily modify the web.config on production, but patching the system would piss off the sys admins. This was the quickest path to a correctly functioning app. That said, I'm notifying infrastructure now. Thanks! ;D – Taylor Sep 17 '13 at 22:44
66

Found this entry on MS Connect, the behavior is a recognized bug.

Suggested Workaround (from the entry):

== Workaround ==

In the meantime to make it work and to avoid similar issues in the future, I use a file ~\App_Browsers\BrowserFile.browser with the following:

<browsers>
<browser refID="Default">
<capabilities><!-- To avoid wrong detections of e.g. IE10 -->
<capability name="cookies" value="true" />
<capability name="ecmascriptversion" value="3.0" />
</capabilities>
</browser>
</browsers>
devio
  • 36,858
  • 7
  • 80
  • 143
  • 7
    Oh my... that's a bit of a bug - I highly doubt all ASP.Net sites are going to be patched by the time of IE10's release. – isNaN1247 Aug 10 '11 at 07:13
  • 2
    thanks for this. it helped me get going on our compatibility testing with our app. it was hard to know at first if it was our app or the beta, but having a workaround made us productive – MikeJ Sep 14 '11 at 21:55
  • This works for me with IE10/Win8, but NOT IE10/Win7. Very strange. – ScottE Mar 21 '13 at 21:22
  • 1
    I am surprised this works for some people because it didn't for me. See cookieless="UseCookies" answer below for an alternative solution that I think is more future proof and robust. – mike nelson Jul 21 '13 at 23:44
33

There is a hotfix available for this issue[1].

1) http://support.microsoft.com/kb/2600088
1) http://support.microsoft.com/kb/2600217 (replaces previous KB)

Also, [2] suggests that this will hit Windows Update in January of 2012.

2) http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.aspx

Derek Slager
  • 13,619
  • 3
  • 34
  • 34
  • 3
    Brilliant, thanks for this - I've promoted the link to the main body of the question for future reference. – isNaN1247 Sep 15 '11 at 07:04
  • 2
    Confirm. It is still a bug as of now (08/2012). I'll try the hotfix. – Eric Nguyen Aug 28 '12 at 08:54
  • 12
    still a bug 04/2013 - wtf? – Scott Selby Apr 04 '13 at 19:45
  • We are hitting this issue still even though we updated the KB Hotfix. I also added the browser files to the Web csproj. Neither seemed to help. What did help, is we added a "site" to the Trusted Sites dialog. Now we are redirecting off of a IFrame from marketplace app on single sign on. I am assuming that there is a less invasive way to handle this redirect, but documentation seems limited on the matter. – Paul Shriner Jul 15 '13 at 16:08
3

Thanks You for the Help. It worked no.

  1. I copied the file from the site to C:\WINDOWS\microsoft.net\Framework\v2.0.50727\CONFIG\Browsers

  2. Run In Command Prompt C:\WINDOWS\microsoft.net\Framework\v2.0.50727>aspnet_regbrowsers.exe -i

  3. Restart the IIS.

  4. Tested the site and it works without any error.

Thanks Again for the Feed back

Apurv
  • 3,723
  • 3
  • 30
  • 51
2

An update for nullptr answer.

I tried today to download the Microsoft KB2600088. After receiving the link by email, I clicked on it then it lead me the page that says it is no longer available.

Try this: http://support.microsoft.com/kb/2600217

That link is a replace ment for KB2600088 and KB2628838.

MIcrosoft .Net Framework 4.5 is also available now.

oski
  • 261
  • 2
  • 3
  • Thanks for posting this update. I was having problems with this link http://support.microsoft.com/kb/2600088 mainly because IE on my server wasn't displayed the page properly. Your update helped me a lot. – Daniel Hollinrake Sep 05 '13 at 09:04
0

Installed the various patches that everyone's mentioning and for whatever reason the problem was not resolved.

Installed .NET Framework 4.5 Full and the problem went away.

You don't have to update any projects to target 4.5. Just install it on the server.

Nate Cook
  • 8,395
  • 5
  • 46
  • 37