16

I am having some trouble holding onto session when opening an initial new tab (target _blank) from IE11.

When I close all instances of IE11 and then open a fresh browser and navigate to the test webpage (default.aspx) the page stores a value in session and displays the session ID on the page. If I refresh the page the session ID stays the same. The page has a link to itself (default.aspx) with a target of _blank. If I click this link a new tab is opened, but the session ID is different. If I then refresh the original window the session ID now matches the new window.

<%@ Page Language="C#" AutoEventWireup="true" Inherits="System.Web.UI.Page" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
<% Session["StoredValue"]="Test"; %>

<div>SessionID: <%=Session.SessionID%></div>

<a href="/default.aspx" target="_blank">New Window</a>
<a href="http://www.google.com" target="_blank">3rd Party Window</a>

</body>
</html>

It appears this problem only occurs for the first window on the same domain opened in a new tab (I have verified the problem with both target="_blank" and by holding CTRL while clicking the link).

  • When I watch the cookie traffic with Fiddler I can see that the session cookie is sent normally in the initial request from default.aspx. When I click the link to open the page in a new tab the session cookie is not being sent in the request headers.
  • If I restart the browser, go to the test page, open a new tab manually and paste the link destination into it the cookie is sent correctly in the request headers and the session from the new tab matches the original tab as expected.
  • If I restart the browser, go to the test page, open google from a link targeting _blank in the test page, and then click the link opening the test page in a new tab the cookie is also sent correctly in the request headers and the session from the new window matches the original window as expected.

I believe this to be a client side issue but the site is running from Windows Server Standard 2008 R2 SP 1 in a 4.0 Integrated website with .NET 4.51 installed (also tried with only 4.5 installed).

The client is Windows 7 64-bit running IE11 (11.0.9600.16476). I have verified the problem on other machines running Windows 7 from IE11 and confirmed that it is not a problem in IE10 from Windows 8 in desktop mode. Everything works as expected in Chrome and Firefox.

I have verified the problem persists even if I:

  • Move security from Medium High to Medium
  • Disable Protected Mode
  • Change privacy to Accept all Cookies
  • Add the site to either the Local Intranet or Trusted Sites zone website list
  • Set a P3P compact privacy policy in the response headers stating no information is collected or used.
  • Set a P3P compact privacy policy in the response headers that would typically be accepted to allow 3rd party cookies within an iframe in past versions of IE.
  • Change the website ASP.NET session state settings to cookieless="UseCookies" or "false" or remove the attribute altogether (ASP.NET State Server).

Any ideas? Has anyone else seen this issue or similar?

user3179118
  • 163
  • 1
  • 1
  • 7
  • The bug report referenced by @user3183307 appears to be the issue I am having. I will contact Microsoft on Monday and attempt to get the status of this and clarify the steps to reproduce as the sample they include is not accurate and does not reproduce the issue as this appears to only be an issue for first party cookies sent from the server. – user3179118 Jan 10 '14 at 21:21
  • Don't forget to upvote and mark the answer as the accepted one. Thanks. – SilverlightFox Jan 10 '14 at 23:13
  • [This is a page link for those who haven't encountered with this bug, yet.](https://www.bayden.com/test/cookie/dupe.aspx). – Cute Bear Aug 20 '14 at 12:34

4 Answers4

5

This is an active bug according to microsoft. There is apparently no server-side way to fix this.

Link to bug report

Mark Pearson
  • 66
  • 2
  • 2
    Just to be precise here: A bug was filed with Microsoft. It remains marked active, but they have not yet stated they can reproduce it. Having said that, the bug is reasonably plausible, as the code area in question already has one other confirmed bug: http://www.debugtheweb.com/test/cookie/dupe.aspx – EricLaw Feb 11 '14 at 14:58
2

Not a solution, but a clue: We noticed similar behavior and tracked it down to requests to root/browserconfig.xml causing user to become unauthenticated. Server sent a new session cookie because Windows was not sending the existing one. Subsequent requests then sent the new session cookie value. We changed our server to look for this request and not set response cookies.

James
  • 133
  • 9
0

This is not a solution, but:

Try middle click instead. If that works for you 100% of the time(it did for me)

js: links with target='_blank' on ie remove defaultBehaviour and trigger middle click.

Problem solved.

T04435
  • 12,507
  • 5
  • 54
  • 54
-1

Same issue coming for my login,But we tried it to resolve it by changing some setting in IE11 or other problematic browsers.

Goto tools=> Internet options=> Privacy There click on Sites button. There add mydomain.com & click on Allow button. Restart your browser.

user1805686
  • 31
  • 2