使用$(request.auth.token.email)在Firestore安全规则中合法以验证访问用户;自己的数据?
我正在开发一个具有两种权限角色(管理员和成员)的应用程序。每当管理员添加会员或其他管理员时,他只需要使用其特定的电子邮件地址添加它们即可。在这种情况下,无论是否注册,都不需要这些电子邮件,并且可以脱机添加这些用户。
问题是,当管理员试图将成员添加到电子邮件中时,我无法在“用户”集合中添加该成员用户ID(可能是新成员),但可以使用其电子邮件地址添加。
因此,要访问他们自己的数据,我想知道是否建议使用$(request.auth.token.email)而不是$(request.auth.uid)在firbase安全文档中推荐。而且,如果您有任何建议,请告诉我。我是Firebase安全规则的新手。
match /shops/{shop} {
allow read, write:
if get(/databases/$(database)/documents/shops/$(shop)/users/$(request.auth.token.email))
.data.admin == true;
}
。
I'm developing an app with two kinds of permission roles (admin and member). Every time an admin adds a member or another admin, he just needs to add them using their specific email address. In this situation, those emails are not required whether registered or not, and also those users can be added offline.
The problem is when an admin tries to add a member with an email, I can't add that member user id (probably a new member) to the 'users' collection but can add using his/her email address.
So, to be accessed their own data, I'm wondering whether it is recommended to use $(request.auth.token.email) instead of $(request.auth.uid) recommended in firebase security documentation. And also, if you have any suggestions, please let me know. I am very new to firebase security rules.
match /shops/{shop} {
allow read, write:
if get(/databases/$(database)/documents/shops/$(shop)/users/$(request.auth.token.email))
.data.admin == true;
}
.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果您想在注册用户之前填写角色,则通过其电子邮件地址进行通用。
如果在这种情况下验证了电子邮件地址,您可能需要添加检查,否则任何人都可以注册您所收听的电子邮件地址之一并获得管理特权。
就个人而言,我将映射从电子邮件地址到角色是这种情况下的临时步骤,并将永久用户记录存储在其UID下,这是更常见的。您甚至可以通过允许用户将角色写入自己的个人资料来完成该客户端,只要它与您在电子邮件之间的映射集合中所拥有的内容匹配。
If you want to prepopulate roles before the user's are registered, going by their email address is common.
You'll probably want to add a check if the email address is verified in that case, as otherwise anyone can register with one of the email addresses you have listen and gain administrative privileges.
Personally I'd see the mapping from email address to role as a temporary step in this scenario, and store the permanent user record under their UID as is more common. You can even do that client-side, by allowing the user to write the role to their own profile as long as it matches what you have in the email-to-role mapping collection.