您如何保护客户端MongoDB API?

[更新] 现在有一个正式的，有文档证明的Auth Package，它提供了不同的解决方案来保护集合.

[UPDATE] There is now an official and documented Auth Package which provides different solutions to secure a collection.

在CRUD级别:

[服务器] collection.allow(options)和collection.deny(options).限制此集合的默认写方法.一旦在集合上调用了这些方法中的任何一个，无论该包是否不安全，该集合上的所有写方法都将受到限制.

[Server] collection.allow(options) and collection.deny(options). Restricts default write methods on this collection. Once either of these are called on a collection, all write methods on that collection are restricted regardless of the insecure package.

还有insecure从客户端删除完全写访问权限.

And there is also insecureto remove full write access from the client.

source: Authentic入门(感谢@ dan-dascalescu)

source : Getting Started with Auth (thanks to @dan-dascalescu)

[旧答案]

显然，正在使用Auth Package(?)，它应该避免任何用户像现在这样对db进行完全控制.还有人建议通过定义您自己的突变(方法)，并通过尝试执行未经授权的操作使它们失败，来提供一种现有的解决方案(解决方法).我并没有得到更好的结果，但是我认为这经常是必要的，因为我怀疑Auth Package是否可以让您在行级别(但可能仅在CRUD方法上)实现常规的auth逻辑.必须要看开发者怎么说.

Apparently there are working on Auth Package(?) that should avoid any users taking full control on the db as it is now. There is also someone suggesting that there is an existing solution (workaround) by defining your own mutations (methods) and make them failed if they attempts to perform an unauthorized action. I didn't get it much better but I think this will often be necessary since I doubt the Auth Package will let you implement the usual auth logic on a row level but probably only on the CRUD methods. Will have to see what the devs have to say.

找到似乎可以证实我想法的东西:

Found something that seems to confirm my thoughts :

当前，客户端具有对该集合的完全写访问权限.他们可以执行任意的Mongo更新命令.建立身份验证后，您将能够限制客户端对插入，更新和删除的直接访问.我们还在考虑验证器和其他类似ORM的功能.

Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality.

此答案的来源:

在客户端访问数据库与服务器端一样有流星

https://*.com/questions/10100813/data -validation-and-security-in-meteor/10101516#10101516