Reputation: 101
So I have a collection right now, structured in the following way
Companies (Collection) -> Company (Document) -> Document has data including the auth UID, plus a subcollection called employs, which has individual employ documents if that makes sense.
I have two questions.
match /databases/{database}/documents {
match /companies/{companyID} {
allow read: if request.auth.uid != null;
allow create,update: if request.auth.uid == resource.data.uid && request.auth.uid == request.resource.data.uid
allow delete: if request.auth.uid == resource.data.uid
}
match /companies/{companyID}/employs/{employID}{
allow read: if request.auth.uid != null
allow write: if request.auth.uid == get(/databases/$(database)/documents/brands/$(document)).data.uid && request.auth.uid == request.resource.data.uid
}
}
So my first question is that, is it fine for other users to be able to read other users UID, because I dont know of a different way to handle write permissions, as I am currently checking to see if the doc id matches the request.auth.uid. In the documentation, they seem to do it similarily. But I just had to make sure that it is fine for user uids to be "public".
Secondly is my implementation right? Is there anything else I should do to achieve the desired results? Please give feedback or suggestions, thanks!
Upvotes: 2
Views: 349
Reputation: 317392
If your security rules are set up correctly, it typically doesn't matter if a UID is known. You'll have to assess that for yourself, however. We can't say for sure without seeing all of the ways you use it in your system.
You'll have to think about it this way: If an arbitrary users know another arbitrary user's UID, what could be known about that other person? If it's possible to get personally identifiable information without their consent, you should probably correct that. If the user's data could be changed any way (again, without their consent), then you also have a problem.
The UID itself doesn't contain any information. It's just a random string. It can't possibly be "spoofed" by an incoming request. request.auth.uid
is always going to be the correct UID for the signed in user, and no one else.
Your rules look OK, but I strongly suggest testing them using the local emulator. You can verify for yourself that they do exactly what you expect, using test code you write.
Upvotes: 2