title: IE silently dropping cookies on iframe page (SSL)?
body: <p>I have a problem with iframes and cookies in a multi-domain web-application.<br /><br />
  Just before I begin, I know very well that application1 on domain1 can't access or set a cookie of application2 on domain2. So it's not a beginner's problem. </p>
  
  <p>The problem is as follows:<br />
  I have website1, located at
  <a href="https://test.xyz-abc.ch/FM_xyz/w8/index.html" rel="nofollow noreferrer">https://test.xyz-abc.ch/FM_xyz/w8/index.html</a></p>
  
  <p>and a reportserver (website2), located at
  <a href="https://www8.company-asp.ch/ReportServer" rel="nofollow noreferrer">https://www8.company-asp.ch/ReportServer</a></p>
  
  <p>The narrowed-down version of the problem is this:</p>
  
  <p>I put this content</p>
  
  <pre><code>&lt;!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"&gt;
  &lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;
      &lt;head&gt;
          &lt;title&gt;Test Page&lt;/title&gt;
      &lt;/head&gt;
  
  &lt;body&gt;
      &lt;iframe src="www8.company-asp.ch/ReportServer/login.aspx" width="1000" height="1000" &gt;&lt;/iframe&gt;
  &lt;/body&gt;
  &lt;/html&gt;
  </code></pre>
  
  <p>into file "ifrm.html" with URL<br />
  <a href="https://test.xyz-abc.ch/FM_xyz/w8/ifrm.html" rel="nofollow noreferrer">https://test.xyz-abc.ch/FM_xyz/w8/ifrm.html</a></p>
  
  <p>Now no matter what I put as username/password on the reportserver form, it doesn't work (the username and password are 120% correct, and exist and have all necessary permissions). 
  <br /></p>
  
  <p>If I do the same thing on Google Chrome or Firefox, then it works, I can login in the Report-Application contained in the iframe. </p>
  
  <p>But in Internet Explorer, you can (attempt to) login, but always stay at the login screen, because for an unknown reason, it either doesn't create the cookie, or it doesn't send the cookie along. </p>
  
  <p>If I run reportserver outside the iframe, i can login and open reports in Internet Exploder. <br />
  Note that ReportServer runs on Forms Authentication (with cookies), not Windows Authentication. </p>
  
  <p>Also, the problem is not specific to ReportServer, I can put any application that uses cookies for authentication in there, and they also fail miserably - but only in Internet Exploder, everything works fine in Chrome and Firefox. </p>
  
  <p>I find this strange, since - if I run the same application (site1) on <br />
  <a href="https://www6.company-asp.ch/FM_xyz/w8/index.html" rel="nofollow noreferrer">https://www6.company-asp.ch/FM_xyz/w8/index.html</a><br />
  and have reportserver on the same domain at<br />
  <a href="https://www8.company-asp.ch/ReportServer" rel="nofollow noreferrer">https://www8.company-asp.ch/ReportServer</a><br />
  , then it works. </p>
  
  <p>Does anybody know what the problem is or might be (I mean apart from the fact that IE is a piece of sh*t software) ? <br />
  The only thing I can think of as difference between the working and non-working variant is that the main domain (the sub-domain is different in both examples) is different.<br /><br />
  Is this a (by design) SSL problem in IE (= serious bug?), or might this be a problem with SSL/SSL-Certificate  misconfiguration ?</p>
  
  <p><strong>Edit:</strong>
  <br />
  Yes, I know I can disable it as in <code>&lt;see below&gt;</code>, but that's not an acceptable solution. I can't tell the client to tell all his employees to alter this setting in their IE. First that never works, second they might not have permission to alter those settings, third the IT department might not allow it, for whatever reasons, and fourthly because it's stupid to ask the customer(s) to alter the settings of their browsers...
  <br />
  <img src="https://i.stack.imgur.com/I7tix.png" alt="P3P"></p>
  
  <p><strong>Edit 2:</strong><br />
  It get's worse. It is P3P, I got it to work on my test-domain using a P3P header via web.config. <br />
  But one cannot add P3P headers in the web.config of ReportServer, because it runs on some kind of internal IIS6.</p>