The data obtained from BaseAuth.verifyIdToken() contains, among other properties, the phone_number and email properties (like detailed here). It can be obtained with DecodedIdToken.phone_number.
What I want to do is hide these fields, so they wouldn't be passed at all in the token.
Is there a way to do that? from what I've seen here, you can add data using a custom token, but I couldn't find any information as for the other way around.
thanks!
The ID token that Firebase Authentication generates contains all information it has for that user. There is no way to hide part of the information from the token.
If you don't want certain properties to be present in the token you should leave them out of the Firebase Authentication profile for that user. For example, you could store them elsewhere, like in one of Firebase's cloud-hosted databases.
Related
I have a signup activity where users sign into firebase. But I want each user to have a different username of the format username#4-digit-code. How can I achieve this with Firestore as i found out with this post that we can't use queries in our transactions?
What would be the best approach for it to prevent two users from having the same userid?
What would be the best approach for it to prevent two users from having the same userid?
The best option that you have is to check if the username#4-digit-code already exists in Firestore. If it doesn't, add it with the corresponding data, otherwise, generate a new one. This operation should continue until you find an user name which is available.
If you want to make sure you aren't doing many checking operations, then you have to make sure you always generate unique user names, or you can use Firebase Authentication, and instead of that username#4-digit-code you can use the UID that comes from the authentication process.
I have an object stored in the Firestore database. Among other keys, it has a userId of the user who created it. I now want to store an email address, which is a sensitive piece of info, in the object. However, I only want this email address to be retrieved by the logged in user whose userId is equal to the userId of the object. Is it possible to restrict this using Firebase rules? Or will I need to store that email address in a /private collection under the Firebase object, apply restrictive firebase rules, and then retrieve it using my server?
TL;DR: Firestore document reads are all or nothing. Meaning, you can't retrieve a partial object from Firestore. So there is no feature at rule level that will give you granularity to restrict access to a specific field. Best approach is to create a subcollection with the sensitive fields and apply rules to it.
Taken from the documentation:
Reads in Cloud Firestore are performed at the document level. You either retrieve the full document, or you retrieve nothing. There is no way to retrieve a partial document. It is impossible using security rules alone to prevent users from reading specific fields within a document.
We solved this in two very similar approaches:
As you suggested, you can move your fields to a /private collection and apply rules there. However, this approach caused some issues for us because the /private collection is completely dettached from the original doc. Solving references implied multiple queries and extra calls to FS.
The second option -which is what the Documentation suggests also, and IMHO a bit better- is to use a subcollection. Which is pretty much the same as a collection but it keeps a hierarchical relationship with the parent coll.
From the same docs:
If there are certain fields within a document that you want to keep hidden from some users, the best way would be to put them in a separate document. For instance, you might consider creating a document in a private subcollection
NOTE:
Those Docs also include a good step-by-step on how to create this kind of structure on FS, how to apply rules to them, and how to consume the collections in various languages
I am wondering whether it is possible to store Widgets(code) in Firebase?
Reason:
I want the user to create a form that is specific to that user, so they can add / remove fields. Clients of the user can then fill that form out based on what fields the user wants.
I have read in other Stackflow Questions for other languages that they convert the code .toString() and store it as a String.
Any feedback would be appreciated!
Storing widgets won't be that much standard. See, the type of fields aren't infinite. What's infinite in your context is how many fields one user can have and the sequence of input fields (Just like a Google Form creation process).
One idea is that you store the sequence of input fields the user has selected and in each sequence you store the label, placeholders of those input fields which are common. Then retrieve those data from fire-base and display with the help of enum.
Yes, you are correct, it's possible to store codes in Firebase, using Flutter. As you mentioned, using the toString() - described in the official Flutter API here - it's possible to override and convert any formats to String, which can be stored in Firebase as you prefer.
However, please, consider checking and verifying the code added, as this is not the better solution and won't be able to add any code to your application as a field. Adding to that, when the code is brought back from the database, you should be able to use it as fields, once you convert the code.
Let me know if the information clarified!
Specifically, should/can one one think of 'Collections' as table names and 'Documents' as unique keys ?
Should you use auto generated key, Auth uid or user email as documents names ?
What are the pros and cons of each if any ?
-Thanks
Yes, collections very closely resemble table names, as they would represent entities in object-oriented perspective. The documents are unique since each must have a unique id, the ids are the unique keys that identify each instance of an entity. No document can share a firebase id with another of the same collection.
Auth id keys seem to be the best idea for user firebase id's as it will allow you to sync between the firebase Auth, and Firestore/Firebase database, right out of the box. This is what I usually prefer. I would use autogenerated id's for other objects which have not been integrated into any other Firebase service. Having a consistent user id for both Firebase Auth,Firestore masks thing quite easy, since I only need to know one id, to access both services from the client end.
Is there a why to let two user login with their own email and password and see the same data?
(Maybe one user well login and be transferred to the other user that has all the data).
Thanks,
Zvi Karp
What you were trying to do is about Database Design, it's actually not about Firebase. (watch out: the link is about relational database design, but Firebase is not using relational database. The idea is the same though.)
There are many ways to achieve your goal. Since you didn't describe your question clearly, I'll just give a general solution:
add a key sahredData to your User entity, and the value of this key is the id of the data you want to share between users. Different users can use the same value in this field(which means they share the same data).
whenever a user needs to access the shared data, use the value of sharedData, which is the id of the shared data, to access the data.