Consider the following case:
User got invitation ticket, after they invite person, the number will decrease. The user can't add the invitation number by their own. Based on the Firebase (Within Function), it seems that it is not suitable for this use case, because once I grant access for user to modify the invitation number for user, they can somehow increase the number or assign any number they want. Is my understand correct? Thanks.
No, security rules can allow you to restrict the data written to the realtime database and by whom.
If you need trusted administrative logic, such as keeping counters you can use Cloud Functions for Firebase or the admin-sdk on a traditional backend.
Related
Similar questions (eg. this) have already been asked and answered in negative. I'd like to if any alternatives exist.
I am developing an application where users can collaboratively edit a document. I don't want to force every user to login. I would like to allow users with a link to be able to edit a document (similar to what Google Docs allows). I was planning to share a token in the link which when presented would grant write access. I would have stored the tokens in a separate collection and matched them. But as per previous answers this is not possible and a security issue.
I don't consider it a security concern (for my purposes). The token is like a pre-shared key. Whoever presents the key is allowed access. If the owner thinks that the key is compromised, he can revoke the same. Kindly help me with a way to achieve this. I'm also curious to know how other apps like Google docs achieve this.
As Mentioned by #Dharmaraj,
In Firebase security rules, you have 3 pieces of information, namely the path, the data and the token. Except from those three you can't pass additional information in a security rule.
Cloud Functions would be a better fit here, given the flexibility. Additionally, with Cloud Functions you'd not be forced to authenticate users, and still be able to connect to Firestore if needed.
I'm currently trying to figure out sign-up for my app. Right now, at sign up I ask users for a username alongside an email and password (for firebase_auth).
The thing is, I don't want more than one user with a username, so I need to check my database if there already exists a user with that username before signing up the user with firebase_auth and adding this new user to my database.
I'm concerned about a race condition that could arise if two users try to create an account with the same username at the same time. I'm trying to use TransactionHandler, but im not sure exactly how I can do this as I hear that a transaction might be run up to 5 times, and we shouldn't do anything that should not be run multiple times (i.e. sign up with firebase_auth?).
Any ideas as to how I can work around this?
There is no way to create a user account and create a document in the database atomically. So you'll have to instead find a way to deal with it in your application code.
Typically this comes from thinking of account creation as a sequence of steps. For example, this is quite common:
Create account in Firebase Authentication, based on the credentials the user enters.
Have the user verify their email address, so that you can reach them.
Have the user claim their unique user name.
You'll see that none of these steps depends on a step that comes after it, so you can execute them in order. And when you do that, step 3 should work fine in a transaction that may run multiple ties.
Just keep in mind: if you want something to be unique on Firestore, you need to use that value as the IDs of your documents. There is no way with client-side access (not even with transactions) to guarantee uniqueness of values across documents. For some more questions on that topic, see:
Firestore unique index or unique constraint?
Cloud Firestore: Enforcing Unique User Names
firebase rule for unique property in firestore, which uses a single document to store all user names.
Prevent duplicate entries in Firestore rules not working
I've developed an app which relies on Firestore for storing some user's data. This app doesn't have any login mechanism, as it uses the device UUID as identifier; we're not managing any sensitive data, btw.
I'm getting daily warnings from Firestore regarding the absence of security rules in my database, but as long as I don't have any login mechanism and my users need to both read and write from it, I can't see any way for implementing a useful security rule.
Is there any pattern I could follow in this situation? Is there any way to create a security rule for allowing to only read and write data created by the same user without any user authentication?
Thanks in advance
It sounds like you want to identify the user, but then without authentication. My guess is that you want to identify them, without requiring them to provide credentials.
If that is the case, you're looking for Firebase's anonymous authentication provider, which assigns a unique, unspoofable ID to each app instance. Signing in anonymously takes very little code, for example for Android it's:
FirebaseAuth.getInstance().signInAnonymously();
After this call completes, the user has an ID that you can then use in your security rules to identify the data from this user.
Firebase is great as it offers a lot of authentication providers. In one of my apps, I use four different providers provided by Firebase (Email, Twitter, Facebook and Google), but I also need to let users sign in via LinkedIn.
As Firebase SDK does not offer LinkedIn, I need to implement the login flow manually, which doesn't seem to be difficult, but there is one huge issue which I see. During the creation of a custom JWT token, I need to assign a user ID. And I have no idea how to generate one while making sure that my approach will not conflict with user IDs which Firebase generate on its own for other providers.
For example, let's imagine that a user Andriy Gordiychuk signs in via LinkedIn and his email address is andriy#gordiychuk.com. A simple way to create a user ID would be to take an email address (andriy#gordiychuk.com) and to randomise it using some hashing function. I would get some random id such as aN59nlphs... which I would be able to recreate as long as the same user signs in. So far, so good.
However, how can I be sure that the ID which I get is not already used by another user who signed in via Twitter, for example?
One way to mitigate this issue is to store LinkedIn user IDs in a Firestore collection. Then, when I need to create a token, I first check whether I already have an ID for this user. If not, I would hash the email address, and I would try to create a user with this ID. If this ID is already occupied, I would then try to create another ID until I stumble upon an ID which is not occupied, and I would then use it.
I don't like this approach for two reasons:
Although the chance that I would generate an already occupied ID
is small, theoretically the process of finding an "available ID" can
take a lot of steps (an infinite loop in a worst-case scenario).
Once I find an available ID, I must store it. Given that all these calls are asynchronous there is a real chance that I would create a user with a suitable ID, but because the save operation fails, I would not be able to use this ID.
So, does anyone know how to choose user IDs for such use case correctly?
It's fairly common to generate a string with enough entropy (randomness) to statistically guarantee it will never be duplicated. This is for example behind the UUID generators that exist in many platforms, and similarly behind Firebase Realtime Database's push keys, and Cloud Firestore's add() keys. If there's one in your platform, I recommend starting with that.
Also see:
The 2^120 Ways to Ensure Unique Identifiers, which explains how Firebase Realtime Database's push() works.
Universally unique identifier, Version 4 on Wikipedia
the uuid npm module
I understand Firebase's security rules for allowing or denying write access for authorized users, however, in a case where you need to allow all users write access to a specific node, say for example in a chat application we need to allow all users to write messages to a support room for example ...
What is the best approach / practice for preventing abuse of a firebase node to which all users have write access to?
Aside from adding limits, like only allowing updates to a node every x number of minutes, are there any other approaches / suggestions out there?