I have been exploring Firebase and from my first impressions it looks really good.
I will use Auth for authentication because it's simple and I do not want to write yet another sign in/up system.
I have been looking at firestore for saving data, because it's simple and I do not have to manage a server.
And here comes the problem; Many of the examples I have seen put rules to show only the current rows with "ID" the Auth UID which they pass from the client.
But can the user can decompile my app, change the UID to other user's UID and read/write to their data?
Is this true or am I missing something?
UIDs are handled by Firebase on the server side. There is no way to reverse engineer an app and change the UID.
If for some reason a user does that or anything similar, he won't be able to login to the app thus won't have access to the data stored on Cloud Firestore.
Related
In my app using Firebase as back-end, I wanted to implement a new feature based on Firebase Storage to allow my users to save some files.
Knowing that my app can be accessed only by people who are paying a subscription, I'm already filtering the access to Firestore (used in my project to store user data) via a document that stores if the subscrition is valid or not and this is filtered by the Firestore security rules.
I saw that there is no linkage between Firestore and Storage, so I can't in the Storage security rules read my Firestore documents. So I had the idea to use CustomClaims to add to the Auth token an attribute if the subscription is valid or not.
After tinkering a bit with it, I noticed and checked that it takes up to an hour to client to have a refreshed token. Since my app follow roughtly this workflow:
I don't think that is a good user experience to wait for an hour to have access to a service the user just paid.
Is there something I didn't see ? Is there a way to circumvent this problem ? Is there an other way to have a refresh token than to force the user to logout ?
You can force the ID token to be refreshed with currentUser.getIdToken(true) with the JS SDK. There are similar methods for the other Client SDKs.
See the doc for more details.
in the app, which logs the user in only through phone authentication.
now the question is can I get the user id from his phone number(not the user id of the current user though).
I have the access to other users phone number in the app, and I want to get their id for further use.
is it possible in flutter with firebase at the backend?
Looking up the UID for a user based on either phone number or email address is considered a sensitive operation. For this reason such operations are only available in the Admin SDKs, which are designed to be used in trusted environments, such as your development machine, a server you control, or Cloud Functions. For more on these, see the bottom two code samples in looking up user data in the documentation.
If you want to perform such operations from your client-side code, your two main options are:
Store the required mapping in a cloud-hosted database, such Firebase's Realtime Database or Firestore, as Huthaifa also answered.
Create your own custom API on a server or Cloud Functions where you lookup the user through the Admin SDK. Your client-side application code can then call this custom API.
In both of these cases you are in full control of what data you share, and how you secure access.
Sure you can, there are multiple approaches for this, if you post your structure for the user model, or how you are storing them in firebase.
You can run a simple Firebase query like this example:
FirebaseFirestore.instance.collection('users').where('phoneNumber', isEqualTo: thePhonenumberOftheuserYouwant2GetUIDfor).get()
You can also store the available\accessible contacts for every user in their user document, and when your user logs in, it'll fetch all their allowed user numbers.
The more information you provide to your problem, the more StackOverflow can provide you back.
my app is fetching data from a Firestore database but this data should only be accessible to users who are currently subscribed to In-App-Purchases.
What is the best way to protect this data?
My first thought was routing everything through a Firebase Function, so the user has to send their subscription ID to the function, the function checks it and returns the data, but this would require way too many function calls for just a few users.
If you are not using any server client libraries then you can create a rule on firestore to restrict the reads on the table.
firestore rules docs..
You could simply check if the requesting user has subscribed to In-App-Purchases (assuming there is a flag in the user's data to confirm the same).
I have a small question about managing data between Firebase Authentication and Firestore.
For example:
The Firebase Authentication API stores the email of the user.
But we also use Firestore to store the other details about the user.
So the question is...
Should we also store the email on Firestore ?
I feel that a duplicate data is never a good idea. But having the email directly in Firestore should be faster and easy to access.
Thank you
I feel that a duplicate data is never a good idea.
When working with NoSQL solutions I'd highly recommend letting that feeling go. Read NoSQL data modeling and watch Getting to know Cloud Firestore for more on this.
One of the things you'll learn from that is that your data model will typically evolve for the use-cases your app needs. For example, if you want to allow the user to see or search all email addresses, that functionality is not standard available in the client-side Firebase Authentication SDK. This means you have a few options to build this functionality for your users:
The server-side Admin SDKs of Firebase Authentication do have the option to look up the email address for a user, or to list users. So you could wrap this functionality in an end-point you create and secure (for example with Cloud Functions).
You can also write the user information to Cloud Firestore (or the Realtime Database) when the users registers, and then look it up there from within the app, using Firebase's security rules to ensure all access to the data is authorized.
This is just one example, and as I hope is clear, it is based on speculating that your app needs certain functionality. But it's quite common that developers store user information that is also in Firebase Authentication in a database too.
I was wondering if getAuth().uid is sensitive/private in anyway? I am planning to use it on a user post something like: post.created_by: getAuth().uid. This makes writing rules/logic a lot easier.
The other way is to use the push id when the user is added to the database, which I'm trying to avoid.
No its safe to use the uid and recommended, firebase uses auth to authenticate the user and the assign the uid to identify the user across firebase.
You will be using uid in your security rules and as well as to identify user info in your db records.
Manually creating another id will render the efficiency of firebase useless.