流星有什么安全机制？

我们都知道，Meteor 提供 miniMongo 驱动程序，无缝地允许客户端访问持久层(MongoDB)。

如果任何客户端都可以访问持久 API，那么如何保护他的应用程序的安全呢？

什么是流星提供的安全机制，在什么情况下应该使用它们？

11247 次浏览
小开

In the collections doc says:

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.

小开

If you are talking about restricting the client not to use any of your unauthorized insert/update/delete API, thats possible.

See their, todo app at https://github.com/meteor/meteor/tree/171816005fa2e263ba54d08d596e5b94dea47b0d/examples/todos

Also, they have now added a built in AUTH module, that lets you login and register. So its safe. As far as you are taking care of XSS , Valiations, client headers etc.

but you can anyday convert meteor app into fully working nodejs application by deploying to node. So if you know how to secure a nodejs application you should be able to secure meteor.

小开
最佳答案

When you create a app using meteor command, by default the app includes the following packages:

  • AUTOPUBLISH
  • INSECURE

Together, these mimic the effect of each client having full read/write access to the server's database. These are useful prototyping tools (development purposes only), but typically not appropriate for production applications. When you're ready for production release, just remove these packages.

To add more, Meteor supports Facebook / Twitter / and Much More packages to handle authentication, and the coolest is the Accounts-UI package

小开

As of 0.6.4, during development mode, is_client and is_server blocks still both go to the client system. I can't say if these are segregated when you turn off development mode.

However, if they are not, a hacker might be able to gain insight from the system by review the blocks of if(Meteor.is_server ) code. That particularly concerns me, especially because I noted that I still at this point can't segregate Collections into separate files on client and server.

Update

Well, the point is don't put security related code in an is_server block in a non-server directory (i.e. - make sure it is in something under the /server .

I wanted to see if I was just nuts about not being able to segregate client and server Collections in the client and server directories. In fact there is no problem with this.

Here is my test. It's a simple example of the publish/subscribe model that seems to work fine. http://goo.gl/E1c56


提交答案