How to debug Safari ITP 2.0 requestStorageAccess failure

Question

I'm currently working on making my code compatible with Safari ITP 2.0. In a method that is triggered on an onClick, I have code similar to the code below:

if (document.hasStorageAccess && document.requestStorageAccess) {
  console.log('On Safari 12');
  document.hasStorageAccess().then(
      function successful(hasAccess) {
        console.log('Testing if hasAccess');
        if (hasAccess) {
          console.log('Access granted already');
        } else {
          console.log('Requesting access');
          document.requestStorageAccess().then(
              function successful() {
                console.log('Access request was a success');
                window.location.reload();
              },
              function fail() {
                console.log('Storage Access API call failed...');
              });
        }
      },
      function rejected(reason) {
        console.log('hasStorageAccess failed: ', reason);
      });
}

However, running this gets me the logging statement "'Storage Access API call failed...'" without a prompt from Safari - what's more frustrating is that it previously worked but is now starting to fail again. Is there any way to debug why the call to requestStorageAccess failed?

I tried enabling the ITP debug mode logs as per the instructions, and I did get some use out of that. It gave me this error once:

2018-09-04 15:15:40.930157-0700 0x110c87 Info 0x0
69100 Safari Technology Preview: (WebKit) [com.apple.WebKit:ResourceLoadStatisticsDebug] Cannot grant storage access to example.com since its cookies are blocked in third-party contexts and it has not received user interaction as first-party.

But when I accessed it in a first party context and reloaded the page, I got no further reasons why the call to requestStorageAccess was failing. If anyone has any ideas, please let me know what you suggest I try to debug the issue.

Thank you!

Answer 1

There are updated debug instructions: https://stackoverflow.com/a/61532464/13443904

But I also wanted to provide some more concrete steps for people struggling with Safari ITP, since it took ages to figure out all the rules.

1) Don't embed requestStorageAccess inside hasStorageAccess. This loses the required user interaction (button click) needed to prompt for requestStorageAccess.

2) hasStorageAccess and requestStorageAccess are promises. Make sure any follow-up actions are nested -inside- the success closures of the promise (ie, if you have a submit button, don't let it submit the form before you've finished asking for requestStorageAccess).

3) You have to set a 1st party cookie and have a user interaction from a top-level window for your subdomain BEFORE you can requestStorageAccess for a 3rd party cookie via user interaction in an iframe for your subdomain. Setting a cookie/interaction in the main domain/parent window does not count.

4) Testing in Safari Technology Preview makes resetting the ITP choices easier - just clear history and quit/reopen and you should go back to scratch. Safari seems to cling to the values forever.

Answer 2

Did you interact (tap/click/form entry) with your website as first party? A mere visit does not suffice. The user has to interact with a webpage with the same eTLD+1 as the domain that is requesting storage access.

Example: 1) service.example is classified with tracking abilities by ITP. 2) The user visits and interacts with a page from service.example or *.service.example. 3) service.example calls the Storage Access API under othersite.example when the user taps in service.example’s iframe.