Firebase云端功能：如何处理连续的请求 [英] Firebase cloud function: how to deal with continuous request

问题描述

在使用Firebase（Firebase云端功能）的情况下，我们必须支付每一个字节的带宽。

所以，我想知道我们该如何处理有人以某种方式找出我们的端点，然后故意连续请求（通过脚本或工具）？

我在互联网上做了一些搜索，但没有看到任何帮助。
除了这一个，但不是很有用。

解决方案

由于您没有指定哪种类型的请求，因此我假设您指的是firebase上的http（s） - 触发器云功能。

有多个限制器可以用来减少请求所消耗的带宽。我会写一些我想到的

$ b

1）限制请求的类型

如果你需要的只是 GET ，比如说你不需要 PUT 在你进入云端功能之前，你需要返回一个403。

  if（req.method === 'PUT'）{res.status（403）.send（'Forbidden！'）; } 
  

2）验证是否可以

按照Google的示例 a>并只允许授权用户使用您的https端点。您可以简单地通过验证令牌像这个SOF答案到这个问题。

3）检查来源

您可以在继续进行云端功能之前尝试检查请求的来源。如果我记得正确的话，云功能可以让你完全访问HTTP请求/响应对象，这样你就可以设置适当的CORS头文件并响应飞行前的OPTIONS请求。

实验想法1

您可以假设您的功能位于负载平衡器/防火墙，然后继电器触发它们。它或多或少会打败云功能可扩展性的目的，但是如果DoS的形式比可扩展性更受关注，那么您可以尝试创建应用引擎中继，将其放在负载均衡器/防火墙之后，并处理这一层的安全。

实验概念2

您可以尝试使用DNS级别攻击防范解决方案通过在之间放入诸如cloudflare的东西来解决您的问题。使用CNAME和 Cloudflare Page Rules 将URL映射到您的云端功能。这可以假设地吸收影响。像这样：

* function1.mydomain.com / * - > https：/ /us-central1-etc-etc-etc.cloudfunctions.net/function1/$2

现在如果你去

http://function1.mydomain.com/?something=awesome

<你甚至可以将URL参数传递给你的函数。我在这篇中文文章中阅读过关于的策略，在夏天，当我需要类似的东西。

最后

为了使SOF上的问题更加联系起来，并帮助每个人找到答案，我发现这是另一个问题，性质类似的这里。链接到这里，让其他人也可以找到它。

When working with Firebase (Firebase cloud function in this case), we have to pay for every byte of bandwidth.

So, i wonder how can we deal with case that someone who somehow find out our endpoint then continuous request intentionally (by a script or tool)?

I did some search on the internet but don't see anything can help. Except for this one but not really useful.

解决方案

Since you didn't specify which type of request, I'm going to assume that you mean http(s)-triggers on firebase cloud functions.

There are multiple limiters you can put in place to 'reduce' the bandwidth consumed by the request. I'll write a few that comes to my mind

1) Limit the type of requests

If all you need is GET and say for example you don't need PUT you can start off by returning a 403 for those, before you go any further in your cloud function.

if (req.method === 'PUT') { res.status(403).send('Forbidden!'); }

2) Authenticate if you can

Follow Google's example here and allow only authorized users to use your https endpoints. You can simply achieve this by verifying tokens like this SOF answer to this question.

3) Check for origin

You can try checking for the origin of the request before going any further in your cloud function. If I recall correctly, cloud functions give you full access to the HTTP Request/Response objects so you can set the appropriate CORS headers and respond to pre-flight OPTIONS requests.

Experimental Idea 1

You can hypothetically put your functions behind a load balancer / firewall, and relay-trigger them. It would more or less defeat the purpose of cloud functions' scalable nature, but if a form of DoS is a bigger concern for you than scalability, then you could try creating an app engine relay, put it behind a load balancer / firewall and handle the security at that layer.

Experimental Idea 2

You can try using DNS level attack-prevention solutions to your problem by putting something like cloudflare in between. Use a CNAME, and Cloudflare Page Rules to map URLs to your cloud functions. This could hypothetically absorb the impact. Like this :

*function1.mydomain.com/* -> https://us-central1-etc-etc-etc.cloudfunctions.net/function1/$2

Now if you go to

http://function1.mydomain.com/?something=awesome

you can even pass the URL params to your functions. A tactic which I've read about in this medium article during the summer when I needed something similar.

Finally

In an attempt to make the questions on SOF more linked, and help everyone find answers, here's another question I found that's similar in nature. Linking here so that others can find it as well.

这篇关于Firebase云端功能：如何处理连续的请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！