我必须在 Collection.allow 和 Collection.deny 中涵盖哪些逻辑以确保其安全? [英] What logic must I cover in Collection.allow and Collection.deny to ensure it's secure?

问题描述

所以刚开始玩 Meteor 并尝试了解安全模型.好像有两种修改数据的方法.

So just started playing with Meteor and trying to get my head around the security model. It seems there's two ways to modify data.

Meteor.call 方法看起来很标准 - 几乎只是调用服务器并实现了自己的业务规则集.

The Meteor.call way which seems pretty standard - pretty much just a call to the server with its own set of business rules implemented.

然后是 Collection.allow 方法，它似乎与我以前做过的任何事情都大不相同.因此，如果您放置一个 collection.allow，您似乎是在说客户端可以对该集合进行任何写入操作，只要它可以通过其允许函数中的验证.

Then there is the Collection.allow method which seems much more different to anything I've done before. So it seems that if you put an collection.allow, you're saying that the client can make any write operation to that collection as long as it can get past the validations in its allow function.

这让我感到不安，因为它给人的感觉有很大的自由度，而且我的允许函数需要很长时间才能确保它被足够安全地锁定.

That makes me feel uneasy cause it's feels like a lot of freedom and my allow function would need to be pretty long to make sure it's locked down securely enough.

例如，mongodb 没有架构，因此您基本上必须有一个规则来定义将接受哪些字段以及这些字段必须采用的格式.

For instance, mongodb has no schema, so you'd have to basically have a rule that defines which fields would be accepted and the format those fields must be in.

您是否还必须为可能对您的系统进行的每种类型的更新都放入业务逻辑.

Wouldn't you also have to put in the business logic for every type of update that might be made to your system.

所以说，我有一个 SoccerTeam 收藏.可能有几种情况我可能需要进行更改，例如添加或删除球员、更改团队名称、团队状态已更改等.

So say, I had a SoccerTeam collection. There may be several situations I may need to make a change, like if I'm adding or removing a player, changing the team name, team status has changed etc.

在我看来，您必须将所有内容都放入这个庞大的函数中.这听起来像是一个激进的想法，但似乎 Meteor.call 方法会简单得多.

It seems to me that you'd have to put everything into this one massive function. It just sounds like a radical idea, but it seems Meteor.call methods would just be a lot simpler.

我是否以错误的方式(或错误的用例?)考虑这个问题? 有没有人有任何示例说明他们如何构建允许或拒绝函数，并列出我可能需要在允许函数中检查的内容使我的收藏安全?

Am I thinking about this in the wrong manner (or for the wrong use case?) Does anyone have any example of how they can structure an allow or deny function with a list of what I may need to check in my allow function to make my collection secure?

推荐答案

您所遵循的推理与我在构建 Edthena 时决定如何处理数据突变时使用的推理相同.开箱即用，meteor 为您提供了进行简单权衡的工具:

You are following the same line of reasoning I used in deciding how to handle data mutations when building Edthena. Out of the box, meteor provides you with the tools to make a simple tradeoff:

我是否信任客户端并获得响应更快的 UI(延迟补偿)?还是我需要严格控制数据验证，但强制客户端等待更新?

Do I trust the client and get a more responsive UI (latency compensation)? Or do I require strict control over data validation, but force the client to wait for an update?

我选择了后者，并且出于以下几个原因专门使用方法调用:

I went with the latter, and exclusively used method calls for a few reasons:

1. 我知道有一种方法可以更新我的每个收藏，我一夜睡得更好.
2. 我发现我的一些更新需要只有在服务器上执行才有意义的副作用(例如，对其他集合进行非规范化更新).
3. 目前，我们的应用没有明显的延迟补偿优势.我们发现大多数写入的延迟对用户体验来说无关紧要.
4. allow 和 deny 规则是弱工具.它们本质上仅适用于验证所有权和其他简单检查.

1. I sleep better a night knowing there exists exactly one way to update each of my collections.
2. I found that some of my updates required side effects that only made sense to execute on the server (e.g. making denormalized updates to other collections).
3. At present, there isn't a clear benefit to latency compensation for our app. We found the delay for most writes was inconsequential to the user experience.
4. allow and deny rules are weak tools. They are essentially only good for validating ownership and other simple checks.

在我们首次投入生产时(2013 年 8 月)，这似乎是一个激进的结论.流星文档、API 和演示突出了客户端写入的使用，所以我不完全确定我做出了正确的决定.几个月后，我第一次有机会与几位流星核心开发人员坐下来交谈 - 这是他们对我的设计选择的反应的总结:

At the time when we first released to production (August 2013) this seemed like a radical conclusion. The meteor docs, the API, and the demos highlight the use of client-side writes, so I wasn't entirely sure I had made the right decision. A couple of months later I had my first opportunity to sit down with several of the meteor core devs - this is a summary of their reaction to my design choices:

这似乎是一种合理的方法.延迟补偿在某些情况下非常有用，例如移动应用程序和游戏，但对于所有 Web 应用程序来说可能并不值得.它还可以制作很酷的演示.

This seems like a rational approach. Latency compensation is really useful in some contexts like mobile apps, and games, but may not be worth it for all web apps. It also makes for cool demos.

所以你有它.在撰写本文时，我对生产应用的建议是在您真正需要速度的地方使用客户端更新，但您不应该因为大量使用方法而觉得自己做错了什么.

So there you have it. As of this writing, my advice for production apps would be to use client-side updates where you really need the speed, but you shouldn't feel like you are doing something wrong by making heavy use of methods.

至于未来，我想在 1.0 之后，我们将开始看到诸如客户端和服务器上的内置架构实施之类的东西，这将对解决我的担忧大有帮助.我认为 Collection2 是朝着这个方向迈出的重要第一步，但我还没有尝试过以任何有意义的方式.

As for the future, I'd imagine that post-1.0 we'll start to see things like built-in schema enforcement on both the client and server which will go a long way towards resolving my concerns. I see Collection2 as a significant first step in that direction, but I haven't tried it yet in any meaningful way.

一个合乎逻辑的后续问题是为什么不使用存根?".我花了一些时间对此进行调查，但得出的结论是，由于以下原因，方法存根对我们的项目没有用处:

A logical follow-up question is "Why not use stubs?". I spent some time investigating this but reached the conclusion that method stubbing wasn't useful to our project for the following reasons:

1. 我喜欢将我的服务器代码保存在服务器上.存根要求我要么将所有模型代码都发送给客户端，要么有选择地再次重复其中的一部分.在大型应用中，我认为这并不实用.
2. 我发现分离可能或可能不会在客户端上运行的内容所需的开销是一项维护挑战.
3. 为了让存根执行除拒绝数据库更改之外的任何操作，您需要有一个允许规则 - 否则您最终会出现大量 UI 闪烁(客户端允许写入，但服务器立即使其无效).但是拥有一个允许规则就无法解决问题了，因为用户仍然可以从控制台写入数据库.

这篇关于我必须在 Collection.allow 和 Collection.deny 中涵盖哪些逻辑以确保其安全?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！