问题
We're integrating our Firebase app with Twitter auth and use the Twitter screen_name as our main human-readable username everywhere in the db.
When it comes to security rules, this is obviously a drawback: We don't know the screen_name as it is not included in auth.token. What we can do, is root.child('users').child($screen_name).child('uid').val() === auth.uid.
Only way to get the Twitter screen_name into the auth.token security rule context is via custom claims, right? What's the preferred method of doing this? Other pattern suggestions for human readable usernames?
回答1:
The option to add custom claims to user tokens is a relatively new addition to Firebase Authentication. Before this feature was available, storing additional information in the database was the only way to accomplish many scenarios. For that reason you'll find that most samples, questions, and documentation shows how to store the additional information in the database.
Storing additional claims in the token has many advantages though. A few of those:
- Custom claims are already available in your security rules, while reading information from the database often requires an additional read.
- Custom claims are available in the security rules for all products, while reading additional information from the database only works in database rules.
There are also a few advantages to using the database to store additional information:
- The information in the database can be relatively unlimited, while the custom claims information must be kept really short.
- I often prefer seeing the additional information in the database, because it's easier to scan the info that way.
If you're using the Twitter screen name in your security rules, it sounds like a natural fit for custom claims. If you also want to show the Twitter screen name for users in the UI, you'll probably also want to store it in the database.
来源：https://stackoverflow.com/questions/47653995/custom-claims-vs-accessing-refs-in-security-rules