1

我正在尝试存储受 CSRF 保护的（查询字符串 + cookie）API POST 请求，以便稍后在 web 应用重新联机时重播。

为此，我想将请求对象（Fetch API）保存在 IndexedDB 中，但 IDBObjectStore.put 失败并出现 DataCloneError “无法克隆对象”。

Request 对象有一个简单的 JSON 主体，没有二进制数据，只有字符串。
这是在服务工作者（网络工作者）环境中运行的。

结构化克隆算法不会克隆请求对象有什么原因吗？[回答： 是] 如果是这样，我最好的选择是脱水/再水化这个对象来代替结构化克隆？

我真的想避免必须知道/访问 Request 对象的各个属性。我需要的请求部分是 url、标头、正文和 cookie（但同样，我不希望代码必须知道这些）。

提前感谢您的任何建议。

4

1 回答 1

4

您确定需要将 auth cookie 和 CSRF 参数存储在 IndexedDB 中，而不是在Request重播时重新生成它们吗？

我们在Google I/O 2015 Web App中遇到了类似的情况，最终只在 IndexedDB 中存储了基本的请求信息（URL + 方法，但序列化的 JSON 主体在概念上是相同的）。每次加载页面并且有可用的有效凭据时，我们都会检查 IndexedDB 以查看是否有任何排队的重播请求，如果有，则使用新的凭据将它们发送到服务器。

我们没有太多选择，因为我们使用的凭据在一小时后过期，但总的来说，只要您使用的凭据有可能过期，这似乎是一个合理的模式。

（如果用户注销，您显然希望清除 IndexedDB 中的排队请求，但无论如何这都是必要的。）

于 2015-10-01T15:38:26.390 回答