HTML5 数据库和 localStorage 可以跨子域共享吗？

Question

我正在尝试使用 Safari 跨子域共享数据。 我想使用 HTML5 数据库（特别是localStorage ，因为我的数据只是键值对）。

但是，似乎无法从sub.example.com访问存储到example.com的数据（反之亦然）。 在这种情况下有没有办法共享一个数据库？

Answer 1

2016 年更新

Zendesk 的这个库为我工作。

样本：

中心

// Config s.t. subdomains can get, but only the root domain can set and del
CrossStorageHub.init([
  {origin: /\.example.com$/,            allow: ['get']},
  {origin: /:\/\/(www\.)?example.com$/, allow: ['get', 'set', 'del']}
]);

注意$用于匹配字符串的结尾。 上面示例中的正则表达式将匹配诸如valid.example.com类的来源，但不匹配invalid.example.com.malicious.com 。

客户

var storage = new CrossStorageClient('https://store.example.com/hub.html');

storage.onConnect().then(function() {
  return storage.set('newKey', 'foobar');
}).then(function() {
  return storage.get('existingKey', 'newKey');
}).then(function(res) {
  console.log(res.length); // 2
}).catch(function(err) {
  // Handle error
});

检查https://stackoverflow.com/a/39788742/5064633

Answer 2

有一种使用跨域的简单方法，只需创建简单的页面，该页面将作为代理iframe包含在您尝试访问的域上，将PostMessage发送到该 iframe 并在 iframe 内进行 LocalStorage 数据库操作。 这是使用 lcoalStorage 执行此操作的文章的链接。 这是向子域中的不同页面发送消息的演示检查源代码，它使用 iframe 和 PostMessage。

编辑：如果浏览器支持，新版本的 sysend.js 库（由上面的演示使用）使用 BroadcastChannel，但它仍然需要 Iframe。 最近的版本还简化了跨域消息的使用，您在 repo 中有 iframe 的 html，您可以使用（或者您可以使用带有 lib 的单个脚本标签的简单 html 文件）并且在父级中您只需要调用一个函数sysend.proxy('https://example.com'); 其中 example.com 需要有proxy.html文件（您也可以使用自己的文件名和不同的路径）。

Answer 3

默认情况下，谷歌浏览器会阻止来自另一个域中的 iFrame 的 localStoage 访问，除非启用了 3rd 方 cookie，iPhone 上的 Safari 也是如此......唯一的解决方案似乎是在不同域中打开父域，然后发送给孩子通过 window.postMessage 但在手机上看起来丑陋和狡猾......

Answer 4

是的。 这是如何：

对于给定超级域的子域之间的共享（例如foo.example.com vs bar.example.com vs example.com ），您可以在这种情况下使用一种技术。 它可以应用于localStorage 、 IndexedDB 、 SharedWorker 、 BroadcastChannel等，所有这些都提供了同源页面之间的共享功能，但由于某种原因，不尊重对document.domain的任何修改，这些修改会让他们使用超级域作为他们的直接出处。

注意：此技术依赖于设置document.domain以允许不同子域上的 iframe 之间的直接通信。 该功能现已弃用。 （尽管截至 2021 年 4 月，它继续在所有主流浏览器中运行，并且可能会保留下来以实现向后兼容性）。

注意：请注意，此技术消除了阻止子域上的恶意脚本影响主域窗口的同源防御，反之亦然，可能会扩大 XSS 攻击的攻击面。 共享主机还有其他安全隐患 - 请参阅MDN document.domain 页面了解详细信息。

(1) 选择一个“主”域作为数据所属的域：即https://foo.example.com或https://bar.example.com或https://example.com将保存您的 localStorage数据。 假设您选择https://example.com 。

(2) 对所选域的页面正常使用 localStorage。

(3) 在所有其他https://*.example.com页面（其他域）上，使用 JavaScript 设置document.domain = "example.com"; （总是超级域）。 然后还创建一个隐藏的<iframe> ，并将其导航到所选https://example.com域上的某个页面（无论哪个页面，只要您可以在其中插入一小段 JavaScript 即可。如果您正在创建站点，只需为此目的专门制作一个空白页面。如果您正在编写扩展程序或 Greasemonkey 样式的用户脚本，因此无法控制example.com服务器上的页面，只需选择您可以找到的最轻量级的页面并将您的脚本插入其中。某种“未找到”页面可能会很好）。

(4) 隐藏 iframe 页面上的脚本只需要 (a) set document.domain = "example.com"; , 和 (b) 完成后通知父窗口。 之后，父窗口可以不受限制地访问 iframe 窗口及其所有对象！ 所以最小的 iframe 页面是这样的：

<!doctype html>
<html>
<head>
  <script>
    document.domain = "example.com";
    window.parent.iframeReady();  // function defined & called on parent window
  </script>
</head>
<body></body>
</html>

如果编写用户脚本，您可能不想将iframeReady()等外部可访问的函数添加到unsafeWindow ，因此通知主窗口用户脚本的更好方法可能是使用自定义事件：

    window.parent.dispatchEvent(new CustomEvent("iframeReady"));

您可以通过将自定义“iframeReady”事件的侦听器添加到主页窗口来检测。

（注意：即使 iframe 的域已经是example.com ，您也需要设置 document.domain = example.com ：为 document.domain 分配一个值会隐式将源端口设置为 null，并且两个端口必须与 iframe 及其父被视为同源。请参阅此处的注释： https ://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Changing_origin）

(5) 一旦隐藏的 iframe 通知其父窗口它已准备好，父窗口中的脚本可以只使用iframe.contentWindow.localStorage 、 iframe.contentWindow.indexedDB 、 iframe.contentWindow.BroadcastChannel 、 iframe.contentWindow.SharedWorker而不是window.localStorage 、 window.indexedDB等...所有这些对象的范围都将限定为所选的https://example.com来源——因此它们将为您的所有页面拥有相同的共享来源！

这种技术最尴尬的部分是您必须等待 iframe 加载后才能继续。 因此，例如，您不能只是愉快地开始在 DOMContentLoaded 处理程序中使用 localStorage。 此外，您可能希望添加一些错误处理来检测隐藏的 iframe 是否无法正确加载。

显然，您还应该确保隐藏的 iframe 在页面的生命周期内没有被删除或导航...... OTOH 我不知道结果会是什么，但很可能会发生不好的事情。

并且，需要注意的是：设置/更改document.domain可以使用Feature-Policy标头来阻止，在这种情况下，该技术将无法如所描述的那样使用。

---

然而，这种技术有一个明显更复杂的概括，它不能被Feature-Policy阻止，并且还允许完全不相关的域共享数据、通信和共享工作者（即不仅仅是公共超级域的子域）。 @jcubic 已经在他们的回答中描述了它，即：

一般的想法是，就像上面一样，您创建一个隐藏的 iframe 以提供正确的访问来源； 但不是直接获取 iframe 窗口的属性，而是使用 iframe 内的脚本来完成所有工作，并且仅使用postMessage()和addEventListener("message",...) .

这是因为postMessage()甚至可以在不同来源的 Windows 之间使用。 但它也明显更加复杂，因为您必须通过在 iframe 和主窗口之间创建的某种消息传递基础架构传递所有内容，而不是直接在主窗口的代码中使用 localStorage、IndexedDB 等 API。