8

我正在构建一个功能齐全的 Web 应用程序。当然，您可以在“离线”模式下保存到本地数据存储。我希望能够跨设备同步，这样人们就可以在一台机器上工作，保存，然后在另一台机器上加载他们的东西。

问题是：

1）在服务器上存储json是一个坏主意吗？为什么要将服务器上的 json 作为 json 传递回（其他）客户端时将其解析为模型对象？

2) 我不确定我是否想为此尝试 NoSql 技术。我没有分解 json，因为现在数据库中唯一的关系是从用户帐户到他们的条目。除了用户数据，域模型将是一个字符串，即 json。欢迎咨询。

理论上，将来我可能想在服务器上做一些处理或者建立更复杂的关系。换句话说，现在我只是保存 json，但将来我可能想要一个更传统的关系系统。NoSQL 方法会阻碍这一点吗？

3）这有什么安全问题吗？例如 JS 注入？理论上，对于这个用例，用户不需要输入任何内容，至少现在是这样。

先感谢您。

编辑 - 感谢答案。我选择了我所做的答案，因为它最详细地介绍了 NoSql 的优缺点。

4

3 回答 3

3

服务器上的 JSON

将 JSON 存储在服务器上并不是一个坏主意，尤其是当您使用 MongoDB 或 CouchDB 等 noSQL 解决方案时。两者都使用 JSON 作为它们的原生格式（MongoDB 实际上使用 BSON，但它非常相似）。

noSQL 方法：假设 CouchDB 作为存储引擎

  • 烘焙复制和并发处理
  • 非常简单的 Rest API，通过 HTTP 与数据库通信。
  • 将数据本地存储为 JSON，而不是存储在 blob 或文本字段中
  • 强大的查看/查询引擎，可让您继续增加文档的复杂性
  • 离线模式。如果互联网不可用，您可以直接使用 javascript 与 CouchDb 对话，并让整个应用程序继续在客户端上运行。

安全

确保您使用浏览器 JSON.parse 或安全的 Javascript 库 (json2.js) 解析 JSON 文档。

结论

我认为我建议在这里使用 noSQL，特别是 CouchDB 的原因是它会为您处理所有困难的事情。复制将是一个快速设置。您不必担心并发性等。

也就是说，我不知道您正在构建什么样的应用程序。我不知道您与客户的关系是什么，以及让他们将 CouchDB 放在他们的机器上会有多容易。

链接

  1. CouchDB @ Apache
  2. 沙发一
  3. CouchDB 权威指南
  4. MongoDB

更新：

在查看应用程序后，我认为 CouchDB 不会是一个好的客户端选项，因为您不会要求人们安装数据库引擎来玩 soduku。也就是说，我仍然认为这将是一个很棒的服务器端选项。如果您想将服务器 CouchDb 实例与客户端同步，您可以使用BrowserCouch之类的东西，它是用于本地存储的 CouchDB 的 JavaScript 实现。

于 2010-11-14T01:41:56.733 回答
3

  1. 如果您的大部分处理将使用 JavaScript 在客户端完成，我认为将 JSON 直接存储在服务器上没有任何问题。

  2. 如果您只是想尝试使用新技术，那么非常欢迎您尝试不同的东西，但是对于大多数应用程序来说，没有真正的理由离开传统数据库，而 SQL 让生活变得简单。

  3. 只要您使用标准JSON.parse函数来解析 JSON 字符串，您就安全了 - 一些浏览器（例如 Firefox 3.5 及更高版本）已经有原生版本，而 Crockford 的json2.js可以在其他浏览器中复制此功能。

于 2010-11-08T00:47:35.437 回答
2

刚读了你的帖子，我不得不说我非常喜欢你的方法，它预示着许多 Web 应用程序将来可能会工作的方式，包括本地存储（用于断开状态）和在线存储（主数据库 - 到将所有客户记录保存在一个地方并同步到其他客户端设备）。

以下是我的回答：

1）在服务器上存储 JSON：我不确定我是否会将对象存储为 JSON，如果您的应用程序非常简单，则可以这样做，但这会妨碍使用数据的工作（运行报告并批量发送电子邮件）以工作为例）。我更愿意使用 JSON 自己传输信息，并使用 SQL 数据库来存储它。

2) NoSQL 方法：我想你已经回答了你自己的问题。我的首选方法是现在设置一个 SQL 数据库（如果所需的额外资源不是问题），这样您就可以节省一些为 NoSQL 设置数据访问层的工作，因为您可能不得不删除它在将来。如果您不想要功能齐全的 RDBMS，SQLite 是一个不错的选择。

如果写一个 schema 太麻烦，你还想把 JSON 保存在服务器上，那么你可以散列一个 JSON 对象管理系统，用一个表并在服务器端进行一些解析以返回相关记录。这样做会比保存/删除文件更容易并且需要更少的权限。

3）安全性：您提到目前没有用户输入：

“对于这个用例，用户无需输入任何内容”

但是在问题的开头，您还提到用户可以

“在一台机器上工作，保存，然后在另一台机器上加载他们的东西”

如果是这种情况，那么您的应用程序将存储用户数据，您没有为他们提供一个很好的 GUI 并不重要，您将不得不从多个角度担心安全性，JSON.parse或者类似的工具只能解决问题的一半（客户端）。

基本上，您还必须检查服务器上 POST 请求的内容，以确定发送的数据是否有效和真实。在保存到数据存储之前，需要在服务器上验证 JSON 对象（或您要保存的任何数据）的完整性（使用 php 或其他类似语言），这是因为有人可以轻松绕过您的 javascript 层“安全”并篡改 POST 请求，即使您不打算这样做，然后您的应用程序无论如何都会将恶意输入发送到客户端。

如果你整理了服务器端的东西，那么JSON.parse在防止 JS 注入方面就有点过时了。拥有额外的层仍然不错，特别是如果您依赖远程网站 API 来获取一些数据。

希望这对你有用。

于 2010-11-08T20:06:44.673 回答