Html5本地数据存储，并跨设备同步
我正在构建一个功能齐全的网络应用程序。当然，您可以在“离线”模式下保存到本地数据存储。我希望能够跨设备同步，这样人们就可以在一台机器上工作，保存，然后在另一台机器上加载他们的东西。
问题是：
1）将json存储在服务器上是一个坏主意吗？当服务器上的 json 只是作为 json 传递回（其他）客户端时，为什么要将服务器上的 json 解析为模型对象？
2）我不确定我是否想为此尝试 NoSql 技术。我不会分解 json，目前数据库中唯一的关系是从用户帐户到他们的条目。除了用户数据之外，域模型将是一个字符串，即 json。欢迎咨询。
理论上，将来我可能想在服务器上做一些处理或者建立更复杂的关系。换句话说，现在我只是保存 json，但将来我可能想要一个更传统的关系系统。 NoSQL 方法会阻碍这一点吗？
3）这是否有任何安全问题？例如JS注入？理论上，对于这个用例，用户不能输入任何内容，至少现在是这样。
先感谢您。
编辑-感谢您的答案。我选择了我所做的答案，因为它最详细地介绍了 NoSql 的优点和缺点。
I am building a full featured web application. Naturally, you can save when you are in 'offline' mode to the local datastore. I want to be able to sync across devices, so people can work on one machine, save, then get on another machine and load their stuff.
The questions are:
1) Is it a bad idea to store json on the server? Why parse the json on the server into model objects when it is just going to be passed back to the (other) client(s) as json?
2) Im not sure if I would want to try a NoSql technology for this. I am not breaking the json down, for now the only relationships in the db would be from a user account to their entries. Other than the user data, the domain model would be a String, which is the json. Advice welcome.
In theory, in the future I might want to do some processing on the server or set up more complicated relationships. In other words, right now I would just be saving the json, but in the future I might want a more traditional relational system. Would NoSQL approach get in the way of this?
3) Are there any security concerns with this? JS injection for example? In theory, for this use case, the user doesn't get to enter anything, at least right now.
Thank you in advance.
EDIT - Thanx for the answers. I chose the answer I did because it went into the most detail on the advantages and disadvantages of NoSql.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
服务器上的 JSON
在服务器上存储 JSON 根本不是一个坏主意，特别是如果您使用 MongoDB 或 CouchDB 等 noSQL 解决方案。两者都使用 JSON 作为其本机格式（MongoDB 实际上使用 BSON，但非常相似）。
noSQL 方法：假设 CouchDB 作为存储引擎
安全性
确保您使用浏览器 JSON.parse 或安全的 Javascript 库 (json2.js) 解析 JSON 文档。
结论
我认为我建议在这里使用 noSQL（特别是 CouchDB）的原因是它将为您处理所有困难的事情。复制将是一个快速设置。你不必担心并发等问题。
也就是说，我不知道你正在构建什么样的应用程序。我不知道您与客户的关系如何，也不知道让他们将 CouchDB 安装在他们的机器上有多容易。
链接
更新：
查看该应用程序后，我认为 CouchDB 不会是一个好的客户端选项，因为您不是需要人们安装数据库引擎才能玩数独游戏。也就是说，我仍然认为这将是一个很好的服务器端选项。如果您想将服务器 CouchDb 实例与客户端同步，您可以使用 BrowserCouch 之类的 JavaScript用于本地存储的 CouchDB 的实现。
JSON on the SERVER
It's not a bad idea at all to store JSON on the server, especially if you go with a noSQL solution like MongoDB or CouchDB. Both use JSON as their native format(MongoDB actually uses BSON but it's quite similar).
noSQL Approach: Assuming CouchDB as the storage engine
Security
Make sure you're parsing the JSON documents with the browers JSON.parse or a Javascript library that is safe(json2.js).
Conclusion
I think the reason I'd suggest going with noSQL here, CouchDB in particular, is that it's going to handle all of the hard stuff for you. Replication is going to be a snap to setup. You won't have to worry about concurrency, etc.
That said, I don't know what kind of App you're building. I don't know what your relationship is going to be to the clients and how easy it'll be to get them to put CouchDB on their machines.
Links
Update:
After looking at the app I don't think CouchDB will be a good client side option as you're not going to require folks to install a database engine to play soduku. That said, I still think it'd be a great server side option. If you wanted to sync the server CouchDb instance with the client you could use something like BrowserCouch which is a JavaScript implementation of CouchDB for local-storage.
如果您的大部分处理将使用 JavaScript 在客户端完成，那么我认为直接在服务器上存储 JSON 不会有任何问题。
如果您只是想尝试新技术，我们欢迎您尝试不同的东西，但对于大多数应用程序来说，没有真正的理由离开传统数据库，而且 SQL 使生活变得简单。
只要您使用标准
JSON.parse函数来解析 JSON 字符串，您就是安全的 - 某些浏览器（例如 Firefox 3.5 及更高版本）已经有本机版本，而 Crockford 的 < a href="https://github.com/douglascrockford/JSON-js/blob/master/json2.js" rel="nofollow">json2.js 可以在其他版本中复制此功能。If most of your processing is going to be done on the client side using JavaScript, I don't see any problem in storing JSON directly on the server.
If you just want to play around with new technologies, you're most welcome to try something different, but for most applications, there isn't a real reason to depart from traditional databases, and SQL makes life simple.
You're safe as long as you use the standard
JSON.parsefunction to parse JSON strings - some browsers (Firefox 3.5 and above, for example) already have a native version, while Crockford's json2.js can replicate this functionality in others.刚读完你的文章，我不得不说我非常喜欢你的方法，它预示着许多 Web 应用程序将来可能的工作方式，同时具有本地存储（用于断开连接状态）和在线存储（主数据库 - 到将所有客户记录保存在一处并同步到其他客户端设备）。
以下是我的答案：
1）在服务器上存储 JSON： 我不确定是否会将对象存储为 JSON，如果您的应用程序非常简单，则可以这样做，但这会妨碍我们的工作使用数据（例如，在批处理作业中运行报告并通过电子邮件发送报告）。我更喜欢使用 JSON 来传输信息，并使用 SQL 数据库来存储信息。
2) NoSQL 方法：我想你已经回答了你自己的问题。我的首选方法是现在设置一个 SQL 数据库（如果所需的额外资源不是问题），这样您就可以节省一些为 NoSQL 设置数据访问层的工作，因为您可能需要删除它将来。如果您不需要功能齐全的 RDBMS，那么 SQLite 是一个不错的选择。
如果编写模式太麻烦，并且您仍然想在服务器上保存 JSON，那么您可以使用单个表和服务器端的一些解析来散列 JSON 对象管理系统以返回相关记录。与保存/删除文件相比，这样做会更容易并且需要更少的权限。
3) 安全性：您提到目前没有用户输入：
但是在问题开始时您还提到用户可以
如果是这种情况，那么您的应用程序将存储用户数据，您没有为他们提供一个漂亮的 GUI 来这样做并不重要，您将不得不从多个角度担心安全性和
JSON.parse或类似的工具只能解决一半的问题（客户端）基本上，您还必须在服务器上检查 POST 请求的内容以确定是否存在问题。在保存到数据存储之前，需要在服务器上验证 JSON 对象（或要保存的任何数据）的完整性（使用 php 或其他类似语言），这是因为发送的数据是有效且真实的。即使您不希望他们这样做，有人也可以轻松绕过您的 javascript 层“安全性”并篡改 POST 请求，然后您的应用程序无论如何都会将邪恶的输入发送到客户端（
如果您整理了服务器端的内容） 。那么
JSON.parse在防止 JS 注入方面就有点过时了。拥有额外的层仍然不错，特别是如果您依赖远程网站 API 来获取一些数据。希望这对您有用。
Just read your post and I have to say I quite like your approach, it heralds the way many web applications will probably work in the future, with both an element of local storage (for disconnected state) and online storage (the master database - to save all customers records in one place and synch to other client devices).
Here are my answers:
1) Storing JSON on server: I'm not sure I would store the objects as JSON, its possible to do so if your application is quite simple, however this will hamper efforts to use the data (running reports and emailing them on a batch job for example). I would prefer to use JSON for TRANSFERRING the information myself and a SQL database for storing it.
2) NoSQL Approach: I think you've answered your own question there. My preferred approach would be to setup a SQL database now (if the extra resource needed is not a problem), that way you'll save yourself a bit of work setting up the data access layer for NoSQL since you will probably have to remove it in the future. SQLite is a good choice if you dont want a fully-featured RDBMS.
If writing a schema is too much hassle and you still want to save JSON on the server, then you can hash up a JSON object management system with a single table and some parsing on the server side to return relevant records. Doing this will be easier and require less permissioning than saving/deleting files.
3) Security: You mentioned there is no user input at the moment:
However at the begining of the question you also mentioned that the user can
If this is the case then your application will be storing user data, it doesn't matter that you havent provided a nice GUI for them to do so, you will have to worry about security from more than one standpoint and
JSON.parseor similar tools only solve half the the problem (client-side).Basically, you will also have to check the contents of your POST request on the server to determine if the data being sent is valid and realistic. The integrity of the JSON object (or any data you are tying to save) will need to be validated on the server (using php or another similar language) BEFORE saving to your data store, this is because someone can easily bypass your javascript-layer "security" and tamper with the POST request even if you didnt intend them to do so and then your application will be sending the evil input out the client anyway.
If you have the server side of things tidied up then
JSON.parsebecomes a bit obsolete in terms of preventing JS injection. Still its not bad to have the extra layer, specially if you are relying on remote website APIs to get some of your data.Hope this is useful to you.