best practice for reacting to third party cookie errors

[dwalker-va]

I was wondering if there was a best practice for reacting to third party cookie errors, as the error message served by the embedded content is not helpful in this context.

It's one of those situations where yes is 100% true, but also given the context that my application has, that my organization has about how often bugs reported about this message end up being related to the client's browser blocking third party cookies, I would like my application to react and offer a little more instruction so that the user can self-serve and fix their issue.

I would have thought that

LookerEmbedSDK.createDashboardWithId(id)
      .withNext()
      .withDialogScroll()
      .withScrollMonitor()
      .withAllowAttr('fullscreen')
      .appendTo(target)
      .withDynamicIFrameHeight()
      .withClassName('looker-embed')
      .build()
      .connect()
      .then(() => {
        this.dashboardLoaded = true;
      })
      .catch((error: Error) => { // important bit
        this.handleLookerSDKError(error);
      });

would be enough to give my application a hint as to when this happened. In handleLookerSDKError I could set a variable that my application could observe and show a different/complementary message, hide the iframe, etc. In testing though, this doesn't work when the embedded page fails to load because the user's browser has blocked third party cookies - the catch block receives no error and what we see in the console is an error being logged in Looker's javascript (as in, javascript inside the iframe) instead of it being piped back through here. Maybe that isn't part of this call and it's happening afterwards? How should I handle that? The session:status event is also not helpful in this regard, in my testing it's not being fired in such a situation.

[fabio-looker]

Found this randomly while searching.

The relevant best practice is here: https://cloud.google.com/looker/docs/signed-embedding#:~:text=you%20need%20to%20make%20sure%20that%20Looker%20shares%20the%20same%20domain

Not sure, but there may be a good place to surface this within the context of the SDK itself?

[dwalker-va]

Thanks @fabio-looker

In our case, we are wanting to use this looker instance across multiple domains. Our customers are able to configure our software to serve it through their own custom domain, so putting our Looker instance on to a particular domain is only helpful for the portion of customers who aren't configuring a custom domain. I was hoping I would have a hook on the client side of the SDK to deal with this kind of error in a more user-friendly/application-contextual way. It does sound like the recommended course of action is "use cookieless embed" instead.

[fabio-looker]

Yes, for an unknown set of parent domains, Cookieless Embed will be the necessary solution (though more work to implement of course)