Cross Origin Iframe Restrictions prevent IndexedDb access on Safari

[balmas]

We are going to need to make some significant changes to this approach for Safari.

Safari does not allow cross-domain Indexeddb access from within an Iframe.

This affects the browser extension as well as the embedded library usage of the lexis-cs services.

Possible workarounds that I see:

1. We might be able to use the StorageAccessAPI (See https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API and https://webkit.org/blog/8124/introducing-storage-access-api/) to explicitly enable access, but I think it probably won't work. The Mozilla docs state the following constraints for embedded content in an Iframe:

Access requests are automatically denied unless the embedded content is currently processing a user gesture such as a tap or click. This also prevents embedded content on the page from spamming the browser or user with excessive access requests.

Origins that have never been interacted with as a first party do not have a notion of first-party storage. From the user’s perspective, they only have a third-party relationship with that origin. Access requests are automatically denied if the browser detects that the user hasn’t interacted with the embedded content in a first-party context recently (in Firefox, "recently" is "within 30 days").

2. Use only volatile (in-memory) storage for Safari

3. Retrieve responses from a fallback remote API if the Permanent Storage with IndexedDb is not available

4. For users of the embedded library, offer an option to deploy the lexis cs service on the same domain

[balmas]

I think we might want to look at the 2nd suggestion above (Retrieve responses from a fallback remote API if the Permanent Storage with IndexedDb is not available) as the first line of attack here. This would allow us to continue to develop the UIs, etc. that rely on the results of data requests, while we work through issues of local storage/access to data.

[balmas]

I think the design of the lexis-cs code allows for this with the abstraction of the desination object -- i.e. we could probably implement an HTTP service destination, couldn't we?