正确的只读Firestore规则适用于iOS应用。

huangapple go评论80阅读模式
英文:

Correct Read-only Firestore rules for an iOS app

问题

I'm developing an iOS application which uses Firestore for getting some data. My app only reads data, never writes.
目前,我正在开发一个iOS应用程序,它使用Firestore来获取一些数据。我的应用程序仅读取数据,不进行写操作。

At the moment I don't use Firebase Authentication.
目前,我不使用Firebase身份验证

I've set rules in Firestore: allow read: if true, but they send me an email with warnings every day: "Database is available for reading for all users".
我已经在Firestore中设置了规则:allow read: if true,但他们每天都会向我发送带有警告的电子邮件:“数据库对所有用户可供阅读”。

  1. So my question is: what approach should I use in my case? If I want to protect the data and minimise the risk of someone (not from my app) can get access to the database.

  2. 因此,我的问题是:在我的情况下,我应该使用什么方法?如果我想保护数据并减少其他人(不是来自我的应用程序的人)访问数据库的风险。

  3. I don't want users to register. For example I can create one account in Firebase Authentication and give permission to it for reading data in Firestore: allow read: if request.auth.uid == "some id" and use this account for each user in the app. But more likely there are some limitations for large amount logged in devices with one account (e.g. some number of log in for one account per a minute), aren't they?

  4. 我不想让用户注册。例如,我可以在Firebase身份验证中创建一个帐户,并为其授予读取Firestore数据的权限:allow read: if request.auth.uid == "some id",然后在应用程序中为每个用户使用此帐户。但更可能存在某些限制,例如一个帐户在一分钟内允许多少设备登录,不是吗?

  5. Also I heard about Firebase App Check which protects API resources from abuse by preventing unauthorised clients from accessing your backend resources (via DeviceCheck or App Attest on Apple platforms). Should I use it in my case?

  6. 此外,我听说过Firebase应用程序检查,它通过防止未经授权的客户端访问您的后端资源(通过Apple平台上的DeviceCheck或App Attest)来保护API资源免受滥用。在我的情况下,我应该使用它吗?

英文:

I'm developing an iOS application which uses Firestore for getting some data. My app only reads data, never writes.
At the moment I don't use Firebase Authentication. I've set rules in Firestore: allow read: if true, but they send me an email with warnings every day: "Database is available for reading for all users".

  1. So my question is: what approach should I use in my case? If I want to protect the data and minimise the risk of someone (not from my app) can get access to the database.
  2. I don't want users to register. For example I can create one account in Firebase Authentication and give permission to it for reading data in Firestore: allow read: if request.auth.uid == "some id" and use this account for each user in the app. But more likely there are some limitations for large amount logged in devices with one account (e.g. some number of log in for one account per a minute), aren't they?
  3. Also I heard about Firebase App Check which protects API resources from abuse by preventing unauthorised clients from accessing your backend resources (via DeviceCheck or App Attest on Apple platforms). Should I use it in my case?

答案1

得分: 0

为了关闭电子邮件通知,请尝试移除全局读取规则,并将其替换为按集合的读取允许规则集合,如下所示。

match /someCollection/{doc} { allow read; }
match /anotherCollection/{doc} { allow read; }

尽量将这些读取和写入规则做得尽可能详细。

至于你的其他问题,如果你的应用程序不使用用户帐户,那就不要使用 Firebase Auth。我建议不要为所有应用用户使用一个认证帐户;从整体来看,这并不合理。对于所有人都有全局读取访问权限的应用没有问题。如果你担心安全问题,可以选择使用 App Check。

英文:

To silence the email notifications, try removing the global read rule and replacing it with a read-allow rule collection by collection, such as the following.

match /someCollection/{doc} { allow read; }
match /anotherCollection/{doc} { allow read; }

Get as granular as you can about these rules for read and write.

As to your other questions, if your app doesn't make use of user accounts then don't use Firebase Auth. I would avoid using one auth account for all app users; this just doesn't make sense in the big picture. There is nothing wrong with an app that has global read access to everyone. And if you have security concerns, just opt into App Check.

huangapple
  • 本文由 发表于 2023年4月4日 05:58:33
  • 转载请务必保留本文链接:https://go.coder-hub.com/75924054.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定