我们都知道 Meteor 提供了 miniMongo 驱动程序,它允许客户端无缝访问持久层(MongoDB)。
如果任何客户端都可以访问持久 API,如何保护他的应用程序?
Meteor 提供了哪些安全机制,应该在什么情况下使用它们?
当您使用流星命令创建应用程序时,默认情况下该应用程序包含以下包:
它们一起模拟了每个客户端对服务器数据库具有完全读/写访问权限的效果。这些是有用的原型工具(仅用于开发目的),但通常不适合生产应用程序。当您准备好发布产品时,只需删除这些包。
添加更多,Meteor 支持Facebook / Twitter / 和 Much More包来处理身份验证,最酷的是Accounts-UI包
在集合文档中说:
目前,客户端被授予对集合的完全写入权限。他们可以执行任意 Mongo 更新命令。一旦我们建立了身份验证,您将能够限制客户端对插入、更新和删除的直接访问。我们也在考虑验证器和其他类似 ORM 的功能。
如果您正在谈论限制客户端不使用任何未经授权的插入/更新/删除 API,那是可能的。
在https://github.com/meteor/meteor/tree/171816005fa2e263ba54d08d596e5b94dea47b0d/examples/todos上查看他们的待办事项应用程序
此外,他们现在添加了一个内置的 AUTH 模块,可让您登录和注册。所以它是安全的。就您处理 XSS、验证、客户端标头等而言。
但是您可以随时通过部署到 node 将流星应用程序转换为完全正常工作的 nodejs 应用程序。因此,如果您知道如何保护 nodejs 应用程序,您应该能够保护流星。
从 0.6.4 开始,在开发模式下,is_client 和 is_server 块仍然都进入客户端系统。当您关闭开发模式时,我不能说这些是否被隔离。
但是,如果不是,黑客可能能够通过查看 if(Meteor.is_server) 代码块从系统中获得洞察力。这让我特别担心,特别是因为我注意到我仍然无法将集合分离到客户端和服务器上的单独文件中。
好吧,关键是不要将与安全相关的代码放在非服务器目录中的 is_server 块中(即 - 确保它位于 /server 下的某个东西中。
我想看看我是否只是因为无法在客户端和服务器目录中分离客户端和服务器集合而发疯。事实上,这没有问题。
这是我的测试。这是发布/订阅模型的一个简单示例,似乎工作正常。 http://goo.gl/E1c56