【问题标题】:How can I protect my Meteor server from an infinite loop on the client?如何保护我的 Meteor 服务器免受客户端无限循环的影响?
【发布时间】:2015-03-08 06:15:39
【问题描述】:

我遇到了客户端上的无限循环导致 Meteor 服务器崩溃的情况。无限循环是我将修复的错误,而不是这个问题的主题。我担心恶意用户可能会创建自己的无限循环并使 Meteor 服务器崩溃。

有问题的无限循环反复调用Meteor.subscribe(...)Meteor.call(...)。看起来这些请求在服务器上排队到无法使用的地步,即使客户端的意图是放弃它们。有没有办法告诉服务器请求已被放弃并将其从队列中删除?

我想这不会保护服务器免受客户端发出数千个连续请求而不放弃它们的影响,所以如果有人有答案,这个问题将取代这个问题。如何限制单个客户端可以发出的请求数?

在这些 APM 图表中,您可以看到无限循环如何影响性能。我在 13:17 左右启动它,在 13:25 应用程序崩溃了(由 Heroku 因超出其内存配额而终止)。

【问题讨论】:

标签: meteor infinite-loop denial-of-service ddp


【解决方案1】:

调用 Meteor.subscribe 时,会在服务器上执行 Meteor.publish 函数。因此,您可以在发布功能中决定不提供数据。

这取决于您是否希望您的用户登录或不提供数据。如果您希望用户登录,您可以创建一个集合,使用所使用的用户 ID 注册对发布函数的任何调用(即任何客户端订阅请求)。每当登录用户尝试订阅并检查此用户最近是否发出多个请求时,您都会询问此集合。如果此客户端达到您定义的请求配额,您可以返回 null。

您可以通过使用https://github.com/gadicc/meteor-headers 包并注册IP 地址来对未登录的用户执行相同的操作。

您可以在客户端meteor.call()重复调用的服务器方法中执行相同操作。

我认为检查这个数据库(它会保持很小,因为只有最近的连接必须保留在数据库中)并决定是否提供数据将比每次提供数据所花费的时间更少。

我希望这会有所帮助。

【讨论】:

  • 谢谢,雨果。所以基本上......@Serkan 所说的。使用速率限制/节流包。
猜你喜欢
  • 1970-01-01
  • 2017-11-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-03-04
  • 1970-01-01
  • 2014-04-01
  • 2015-10-26
相关资源
最近更新 更多