none
Log in fails - cookie is not sent to originating tab

    Question

  • Hi all!

    I have 2 webservers, one with an SSO application and one with the core application. Both built on .Net 3.5.
    Both sites have valid P3P.

    Client machine is using IE 10 on Win 7. Also reproduced with Terminal server and IE 9, Windows 7 with IE 8 and 9.

    I open Internet Explorer with fresh session. In the first tab I go to e.g. google.com
    In the second tab I navigate to the SSO.
    I log in and see (in div. tools like Fiddler2 and BurpSuite) that the cookie is issued.
    However, during the redirect to the core application, the cookie is dropped.
    During troubleshooting I can see that if I go back to the "google tab" (first tab), and type in the url for the core application, I am automatically logged in and the cookie is valid.
    It seems that the cookie is not returned to the originating tab.
    The problem could be related to this patch, however, the problem still occur after the patch has been deployed: http://support.microsoft.com/kb/2854669

    This problem does not happen in IE if I only have one tab open. So if I navigate directly to this site in the first tab, I am logged in and can work as normal just fine.
    To make it a bit more interesting, this problem does not happen in FireFox, Opera, Safari or Chrome.
    And to make it even more interesting - in IE private browse mode, the problem does not happen.
     
    I can fix this manually be implementing the "workaround" mentioned in this blog: http://blogs.msdn.com/b/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx.

    Note that this workaround is not "enterprise-friendly" as I cannot instruct my customers to change the registry in order to use the core application.

    It seems that IE has some trouble managing client cookies.

    Anyone with an idea?
    Saturday, November 16, 2013 8:05 PM

Answers

  • Our investigation determined that the site in question was sending two Set-Cookie response headers that set a cookie of the same name; one was a Session cookie and one Persistent cookie. For whatever reason, this is intermittently causing neither version of the cookie to be preserved. Reduced repro.

    I've escalated this to the engineering team for investigation. The workaround for the server is to only set the cookie once.

    • Marked as answer by sonstabo Thursday, November 21, 2013 7:13 AM
    Wednesday, November 20, 2013 5:46 PM

All replies

  • InPrivate mode, by default runs with Addons (toolbars and BHO's) disabled.

    the first step in troubleshooting web browser issues is to test in noAddons mode.

    the second is to check that your IE Security zone settings are at the recommended defaults.

    IE10 can be run in Enhanced Protected Mode... tabs in different domains may be sandboxed. IE10 supports the sandbox attribute for iframes. IE10 has tracking protection which may be blocking the google core and analytics api's.

    Post consumer questions about IE to http://answers.microsoft.com. Include with your questions the address of any websites you are having problems with.

    Regards.


    Rob^_^

    Sunday, November 17, 2013 3:33 AM
  • Dear Rob, thank you for answering.

    I have tested the site with "noAddons" mode. The same problem happens.

    I have also tested this with clean installations of IE 10 on top of a clean installation of Win7 with latest SP and security updates only. No trusted sites or similar has been configured for the site in the browser. The problem is still the same.

    There are no iframes in play, and there are no "external-third-party" stuff that (might) play a role here. 

    The fact that IE send the cookie back to the "home"/first tab instead of the tab I'm actually working with/from indicates to me that IE has a (possible serious) error as it doesn't have control of it's cookies. Which can be a serious security flaw. This can be verified with different machines over and over again.

    What I have noticed is that the problem happens more often on 64 bits computers than computers with 32 bits. 

    The site is live and kicking and I can provide a test-login to people that would like to verify this for themselves.

    This is not an IE 10 consumer question - this is more a "IE 10 bug report", I just do not know where to submit it :) I originally submitted it here btw, http://answers.microsoft.com/en-us/ie/forum/ie10-windows_7/log-in-fails-cookie-is-not-sent-to-originating-tab/95cc29ac-c100-498c-8280-e07989f94b07?tm=1384508601939, but sent to this site.

    Please also note this reference, http://support.microsoft.com/kb/2854669/en-us, that still doesn't work for my part.

    Br,

    Ivar

    Monday, November 18, 2013 1:49 PM
  • Please email me your repro information (e_lawrence on Hotmail) and I'll debug this for you.

    thanks!

    Monday, November 18, 2013 7:28 PM
  • Dear Eric,

    E-mail with credentials and information sent to the specified e-mail.

    Br,

    Ivar

    Monday, November 18, 2013 8:45 PM
  • Our investigation determined that the site in question was sending two Set-Cookie response headers that set a cookie of the same name; one was a Session cookie and one Persistent cookie. For whatever reason, this is intermittently causing neither version of the cookie to be preserved. Reduced repro.

    I've escalated this to the engineering team for investigation. The workaround for the server is to only set the cookie once.

    • Marked as answer by sonstabo Thursday, November 21, 2013 7:13 AM
    Wednesday, November 20, 2013 5:46 PM
  • I'm impressed with Eric's interest in this issue and his ability to help us out! Thumbs up :)
    Thursday, November 21, 2013 7:14 AM
  • Was this issue resolved? Can you please let us know.
    Thursday, May 8, 2014 6:56 AM
  • Internet Explorer has not yet issued an update to fix the "Duplicate Set-Cookies in a single response can result in cookie delete" bug.

    You can easily test this yourself using the Reduced Repro link: https://www.bayden.com/test/cookie/dupe.aspx

    Thursday, May 8, 2014 4:18 PM