Short question(s): What are the risks/problems if I expose another users' UID on the client side?
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.
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
}
}
}
}
}
My thinking is this.
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.
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.
If confirmed, the client side retrieves the requester's uid from the request message, and pushes it to the "authorized" field
user A's private data can then be readable by the uid listed in the authorized field.
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.
I'm new to firebase database and user-authentication in general, so pardon my french :) Thanks in advance to all the gurus out there.