Bug: DOMException / security in cross-origin private browsing mode situations

[kyr0]

Hi,

there is an issue with a specific security condition where this hook can potentially break a whole web application, also production deploys, just by using it in the intended way.

If you integrate a web app inside of an <iframe> but this <iframe> is not served from the same domain, we have a typical "vertical" / "whitelabel" / "intranet integration" / "extranet integration" use-case.

This standard use case can potentially break a whole application and render a white-screen in production when the user is visiting that site in private mode. In this condition, browsers like Chrome and Firefox activate specific security rules that cause a DOMException to happen, only if you just try to read window.sessionStorage / window.localStorage in your code:

This is happening here:
https://github.com/tiaanduplessis/react-hook-form-persist/blob/master/src/index.js#L16

And causes:

...based on production transpiled and minified code from this lib:
react-hook-form-persist.js":function(e,t,n){var r=n("../../node_modules/react/index.js");e.exports=function(e,t,n){var a=t.watch,o=t.setValue,i=void 0===n?{}:n,s=i.storage,l=void 0===s?window.sessionStorage:s,

There are two ways to fix this:

• you can wrap every use of the hook in try/catch
• we can do that in the lib and provide a mock storage implementation, backed by a global variable object to persist data (more or less like sessionStorage, just that it wouldn't survive hard reloads, which is probably better than breaking code completely and at least gives a working app in most cases; just needs to be documented well)

I have that in code already and can PR it.

Are you aware of this thing and would you accept a PR?

[tiaanduplessis]

Hi @kyr0. Thank you for creating the detailed issue and sorry for the delayed response. I wasn't aware of it and will be very happy to accept a PR that resolves it.