WICG / first-party-sets

Home Page:https://wicg.github.io/first-party-sets/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to get related websets working

anand-work opened this issue · comments

Hello, we are having issues getting related web sets to work and would appreciate some assistance. We have our inhouse iam hosted at iamsite.test. Our main application is hosted at mainapp.test. We have another service site hosted at servicesite.test.

User first goes to mainapp.test. User clicks a “login button”, the login window is shown in a popup window and user is redirected to the iamsite.test. User goes through the OIDC login process. iamsite.test sets cookies for session and redirects user back to mainapp.test. When user clicks an “open service” button in mainapp.test, we add a new <iframe> and load servicesite.test. When servicesite.test loads, it initiates the OIDC authorize flow within the iframe to iamsite.test. Since the user is already logged in and the iamsite cookies are present in the request the user is not challenged and iam redirects user back to servicesite.test in the iframe.

This flow is broken when we block third party cookies. We are trying to solve this using related web sets. I created a related web set with all three sites and added it to chrome using --use-related-website-set command line argument.

chrome --use-related-website-set="{\"primary\": \"https://mainsite.test\", \"associatedSites\":[\"https://iamsite.test\",\"https://servicesite.test\"]}"

I confirmed the related web set was added by browsing to chrome://system. I then added two calls to requestStorageAccessFor (for both the servicesite.test and iamsite.test). These methods are executed when user clicks the “open service” button in mainsite.test but before the <iframe> is created. This call succeeded without any errors. But, after the iframe is added and the oidc login flow is initiated within the iframe to iamsite.test, the iam cookies are still not being passed.

The mdn document has the following

“requestStorageAccessFor() can enable third-party cookie access for cross-site resources directly embedded into a top-level site that are unable to request storage access themselves, for example elements. Cross-site content embedded in <iframe>s that has its own logic and resources and needs third-party cookie access should request storage access via Document.requestStorageAccess().”

But, the google website has no such recommendation.

Would requestStorageAccessFor work for requesting access for all iframes in the page (including ones that are currently not rendered in the page)?

Any thoughts on what is wrong with our implementation?

Sample code

<html>
  <head>
    <script>
    function buttonClick() {
      /* This fetch does not send cookie */
      fetch(
        "https://<iamsite.test>/endpoint",
        {
          method: "GET",
          credentials: "include",
        }
      )
      .then((response) => {})
      .then((json) => {});
    document
      .requestStorageAccessFor("https://<iamsite.test>")
      .then(
        (_) => {
        /* This fetch sends cookies */
        fetch(
         "https://<iamsite.test>/endpoint",
         {
           method: "GET",
           credentials: "include",
         }
        )
        .then((response) => {})
        .then((json) => {});

        /* This image request does not send cookies */
        var imageElement = document.getElementById("imageid")
        imageElement.src = "https://<iamsite.test>/imageendpoint";

        /* This frame request does not send cookies */
        var iFrameElement = document.getElementById("frameid");
        iFrameElement.src = "https://<iamsite.test>/endpoint";
      },
     (_) => {     
     }
   );
  }
  </script>
</head>
<body>
  <img id="imageid" crossorigin></img>
  <iframe id="frameid"></iframe>
  <button id="mybutton" onclick=buttonClick()>My button</button>
</body>
</html>

When you say you're blocking third-party cookies, could you verify if you are testing using chrome://flags/#test-third-party-cookie-phaseout enabled?

Thanks for the response. I tested it with that flag enabled and the sample attached above did not work.

Some workflows in our application that did not work when third party cookies were blocked (under Tools->Settings->Privacy and security) started working after chrome://flags/#test-third-party-cookie-phaseout was enabled (even without rws). Based on my understanding that was due to the heuristics based exceptions. But, that is a different discussion. We would first like to figure out why the sample code attached above does not send cookies when the request is made from an iframe.

requestStorageAccessFor(origin) allows the top-level document to issue credentialed fetches to origin (via CORS), but it does not make embedded iframes include cookies automatically. Embedded iframes must still call requestStorageAccess() (which will resolve automatically, without requiring a user gesture) in order to obtain access to their cookies.

I.e., in your case mainsite.test should call document.requestStorageAccessFor("https://iamsite.test"), and then the iamsite.test iframe should call document.requestStorageAccess(). Then it should have access to its session cookies.

There hasn't been any activity on this issue in a some months, so I'm going to assume it has been resolved. Closing.