<html>
    <head>
      <base href="https://bugs.webkit.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Navigation from CodePen iframe to CodePen top frame makes CodePen servers think the user is not logged in"
   href="https://bugs.webkit.org/show_bug.cgi?id=233128#c2">Comment # 2</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Navigation from CodePen iframe to CodePen top frame makes CodePen servers think the user is not logged in"
   href="https://bugs.webkit.org/show_bug.cgi?id=233128">bug 233128</a>
              from <span class="vcard"><a class="email" href="mailto:wilander@apple.com" title="John Wilander <wilander@apple.com>"> <span class="fn">John Wilander</span></a>
</span></b>
        <pre>(In reply to Chris Coyier from <a href="show_bug.cgi?id=233128#c1">comment #1</a>)
<span class="quote">> Thanks so much for opening this John! Indeed this is a weird bug we've been
> trying to track down without luck so far. To answer the questions....

> 1) They are definitely logged out. There is a cookie called `cp_session`
> that just gets wiped out after the link click. <a href="https://d.pr/i/bVoA1A">https://d.pr/i/bVoA1A</a></span >

Is the cookie deleted, you say? Is it the server that deletes it or overwrites it with a new one?

What I would assume here is one of these things happening:

a) The navigation from the iframe to the top frame doesn't carry the SameSite=lax cookie and so the resulting page load shows the user as logged out. However, a fresh of that page would show the user as logged in again because now the SameSite=lax cookie is sent.

b) The navigation from the iframe to the top frame doesn't carry the SameSite=lax cookie and the server deletes/overwrites some state in the response based on thinking that the user is not logged in. Even a fresh of the page will show the user as logged out because now their login cookie is indeed gone or overwritten.

<span class="quote">> 2) Yeah there is no need to attempt to see if a user is logged in or not
> with the embed itself.

> 3) Looks like SameSite = Lax (is this the culprit?)</span >

It could be. We've had cases where our logic for SameSite (lax or strict) cookies has differed from Gecko and Chromium. Sometimes there is no standardized test so it's a case of a de facto standard. See this one for instance: <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - Javascript can't access a SameSite=Strict cookie after page is loaded after a redirect from a third party site"
   href="show_bug.cgi?id=208049">https://bugs.webkit.org/show_bug.cgi?id=208049</a>

<span class="quote">> 4) No ServiceWorkers in use.</span >

Good to know.

Some follow-up questions:

5) To make sure, is the `cp_session` cookie …
 a) … just not sent in the navigation but still there on a reload or fresh load?
 b) … deleted by WebKit during the navigation?
 c) … deleted by the server in the navigational response? Deleted here means set to an expiry in the past.
 d) … overwritten by the server in the navigational response?

6) Are there any cross-site redirects in the navigation or does it go directly to the destination site?

7) Are there any same-site redirects in the navigation does it got directly to the destination page?

8) Can you share the link to reproduce the issue?

Thanks!</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>