Are there any problems with using a user's UID (which is generated by Firebase upon user creation via Firebase Auth) as the key for associated database entries?
For example, here:
/config/user.uid/configObject
...each user has one config entry. Due to Firebase's database rules (where settings on a parent node apply to all child nodes) it's often necessary to create a separate config tree (following the example, where a /users tree needs to be read and write protected).
The only reason I can see that this might be bad practice is if the user's UID ever changes... Does Firebase guarantee that this will never happen? Anything I'm missing?
The UID for a particular user will never change (though they did change the format a few months ago; the old format included the provider).
It's a good practice, a necessary one in many cases, and probably recommended somewhere. You'll want to denormalize user info into multiple nodes for better performance and for authorization as you mentioned. It might look something like this in pseudo code/rules:
- users_private (.read: $uid == auth.uid)
- $uid
- email
- users_public (.read: true)
- $uid
- name
- photo
- users_roles (.read: dependent on some other rules)
- $uid
- is_admin
- is_editor
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments