【问题标题】:Why does Google Firebase Cloud Firestore has "write", "update" security rules, while we should not allow users to write directly on database?为什么 Google Firebase Cloud Firestore 有“写入”、“更新”安全规则,而我们不应该允许用户直接在数据库上写入?
【发布时间】:2021-07-21 09:05:51
【问题描述】:

我正在实施一个使用 Google Firebase Cloud Firestore 的应用程序。因为我的应用程序有很多小的写入请求,如果我在中间使用 Firebase Cloud Functions 会非常昂贵。因此,我在Should we allow users to write to database directly 上提出了一个问题。所有的回应都说我不应该这样做。那么,为什么 Google Firebase Cloud Firestore 有“写入”、“更新”安全规则呢?无论如何,用户都不应该写入数据库。

EDIT(回应 DIGI 的评论和回答): 从答案来看,我们似乎可以改用 firebase 规则。那么,我们应该如何正确使用它们呢?

例如,当用户打开地图并将其更新到数据库时,我的应用程序正在记录用户的位置,以便用户的朋友可以实时看到它。我应该如何确保数据的形式是{longtitude: double, latitude: double, timeStamp: TimeStamp},并且用户不会更改文档中的任何其他几项?

【问题讨论】:

  • 这篇文章可以使用一些格式和说明,将其方向从固执己见转向基于解决方案。您能否重新表述您的问题,使其符合 Stack Overflow 准则?

标签: firebase firebase-realtime-database google-cloud-firestore google-cloud-functions


【解决方案1】:

这是标准 MySQL 数据库的常见误解,在服务器充当逻辑层并位于客户端和数据库之间的类似情况下。

Firebase 在称为security rules 的简化版本中仍然具有这一层逻辑,它允许来自客户端的基本读写操作。该设计是通过将计算能力从服务器后端转移到客户端,通过将需求分配给用户的设备来节省后端的服务器计算成本。

SE 中列出的担忧来自那些不了解您可以在规则和项目中设置的限制和限制,以控制 Firebase 和您的应用可以请求的内容。

澄清一下,Firebase 不会隐藏您的数据库密钥,它们很容易访问,是的,理论上用户可以使用您的数据库后端创建客户端。但只要规则到位、条件定义、Cors 配置和应用源设置得到执行,您就可以阻止所有这些。

【讨论】:

【解决方案2】:

对于多次写入,Realtime 是理想的选择,因为它可以比 Firestore 写入更快、更具成本效益地处理数据。 因此,我的示例将根据您的编辑以实时数据库的意图进行响应。

{
 “rules”: {
 “location”: {
 “$uid”: {
 “.validate”: “newData.hasChildren(['longtitude', 'latitude', 'timestamp']) &&
               newData.child('longtitude').isNumber() &&
               newData.child('latitude').isNumber() &&
               newData.child('timestamp').val() <= now”, 
 }
 }
 }
}

我强烈建议您熟悉一些核心概念

https://medium.com/@juliomacr/10-firebase-realtime-database-rule-templates-d4894a118a98

完整文档在这里:https://firebase.google.com/docs/reference/security/database

【讨论】:

    猜你喜欢
    • 2018-12-26
    • 2018-01-05
    • 2021-12-11
    • 1970-01-01
    • 2020-11-22
    • 1970-01-01
    • 2019-11-02
    • 2019-09-27
    • 2021-06-24
    相关资源
    最近更新 更多