Firebase 数据库 - 与在客户端公开 uid 相关的风险? [英] Firebase Database - Risks associated with exposing uid on the client side?
问题描述
简短问题:如果我在客户端暴露其他用户的 UID，会有哪些风险/问题?
Short question(s): What are the risks/problems if I expose another users' UID on the client side?
我的情况:我正在构建一个测试 android 应用程序，它需要能够让 1) 用户 foo 请求授权，以便 2) 访问用户 A 的私人数据.
My circumstance: I'm building a test android app that needs to be able to let 1) user foo request authorization in order to 2)access user A's private data.
我不知道这是否是废话"事实，但我似乎无法在 Firebase 上找到关于不要公开 UID"的任何警告.我一直在浏览用户安全部分和 Firebase 的聊天示例演示，常见的方法似乎是创建一个字段共享"或授权"，授权用户的 uid 为真.我的问题主要是关于第一步.下面是我的数据结构的片段.
I don't know if it is a "duh" fact, but I just can't seem to find any warning on Firebase about "DON'T EXPOSE UID". I've been skimming on the user-security section and Firebase's chat example demo, and the common approach seems to create a field "share" or "authorized" with the authorized user's uid as true. My question is primarily about the first step. Below is a snippet of my data structure.
{
"users" : {
"uid_of_user_a" : {
"requests" : {
"-KeXTQeFJ2gAiaazteO1" : {
"requestUid" : "uid_of_user_foo",
"targetUid" : "uid_of_user_a",
"timeStamp" : 123456
}
}
}
}
}
我的想法是这样的.
请求字段的规则是用户可以读/写uid_of_user_a，并且只有在此类用户的情况下才可对任何经过身份验证的用户写入推送与 uid_of_user_a 匹配的 targetUid.
The rules for the request field is it is read/write for user with uid_of_user_a, and writable for any authenticated users only if such user push in the targetUid that matches uid_of_user_a.
在客户端，用户 A 附加了一个 onChildEventListener，并附有对该字段的引用.当客户端收到 onChildAdded 回调时，会出现一个对话框并要求确认.
On the client side, user A has a onChildEventListener attached with a reference to this field. When the client receives a onChildAdded callback, a dialog shows up and asks for confirmation.
如果确认，客户端从请求消息中检索请求者的uid，并将其推送到已授权"字段
If confirmed, the client side retrieves the requester's uid from the request message, and pushes it to the "authorized" field
用户 A 的私人数据可以被授权字段中列出的 uid 读取.
user A's private data can then be readable by the uid listed in the authorized field.
问题:需要向客户端公开另一个用户的 uid.这种方法就像打电话给某人一样，呼叫者必须先知道接收端的电话号码.因此，在不实际提供电话号码和电子邮件的情况下，有人必须以某种方式知道 UID，以便甚至可以通过消息传递并要求获取可共享的数据，对吗?....但是，我的直觉方法似乎不确定.
Problem: Exposing another user's uid to the client is required. This method is comparable to like calling someone on a phone, the caller has to know the receiving end's phone number first. so, without actually giving out phone numbers and email, someone has to know the UID somehow in order to even get a message across and ask to get shareable data, right?.... but, my intuitive approach seems iffy.
我是 firebase 数据库和用户身份验证的新手，所以请原谅我的法语 :) 在此先感谢所有的大师.
I'm new to firebase database and user-authentication in general, so pardon my french :) Thanks in advance to all the gurus out there.
推荐答案
UID 只是一个字符串.里面没有任何信息.这条秘密信息是用户的密码(您永远看不到)和他们的临时身份验证令牌，该令牌将在一个小时后过期.SDK 将自动刷新该令牌.
A UID is just a string. There's no information in it. The piece of secret information is the user's password (which you can never see) and their temporary authentication token, which expires after an hour. The SDK will automatically refresh that token.
如果您的安全规则设置正确，则没有问题.如果一个用户知道另一个用户的 UID，那么在您的规则不允许的情况下，第一个用户无法影响第二个用户的数据.您可能希望将有关用户的公共和私人信息分成 单独的位置 以便他们可以有单独的安全规则(如果您需要的话).
If your security rules are properly set up, there is no problem. If one user knows another user's UID, there's nothing the first user can do to affect the data of the second user if your rules don't allow it. You may want to separate public and private information about users into separate locations so they can have separate security rules, if that's what you need.
如果出于某种原因您仍然认为 UID 需要保密，您可以生成一个不同的 UUID 或其他东西来识别用户并使用它，但我不知道这会提供什么额外的安全性.
If for some reason you still think that the UID needs to be kept secret, you can generate a different UUID or something to identify the user and use that instead, but I don't know what extra security that will provide.
这篇关于Firebase 数据库 - 与在客户端公开 uid 相关的风险?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
