I've started designing a referral system and wanted to use firebase auth UIDs as the referral code for each user, however they're longer than I'd like and also not guaranteed to stay small. I've looked into some libraries for short text compression, hashing, etc; But none seem to satisfy my needs. I've recently came across the lovely short-uuid pkg on npm but unfortunately it doesn't seem it works with firebase UIDs(because those aren't UUIDs) but i've been looking for a possible solution that doesn't involve keeping a lookup table of custom IDs to UIDs.
So the real question: is there any good way to compress a short string programmatically and then decompress?
There is no way for you to control the UIDs that Firebase Authentication generates in its various providers.
If you want to use a shorter/friendlier scheme for identifying your users, some options are:
You can generate a shorter ID yourself, and maintain a mapping of those IDs to the ones that Firebase generates. You'll typically want to include a uniqueness check for your shorter IDs, as the chances of collisions rapidly go up for the shorter strings.
A common example of a friendlier identifier for users is to allow users to pick a unique username. This is essentially a variant of the first option, but now with a user-selected ID. Here too you will need to perform a check to prevent duplicates.
You can also creating a custom provider that plugs into Firebase Authentication. When doing this, you control the UID that Firebase uses too. Here you are responsible that the UIDs your provider generates are unique not just within your own provider, but across all providers you've enabled for your project.
As #FrankVanPuffelen explained there is no way for you to control the UIDs that Firebase Authentication automatically generates.
But with the createUser() method of the Admin SDK you can define which UID you want to assign to a new user. As explained in the doc, "if you instead want to specify your own UID for the new user, you can include it as an argument passed to the user creation method"
await admin.auth().createUser(
{
uid: 'some-uid',
email: 'user#example.com',
password: '....',
}
);
You can run this code in a Cloud Function or on a server you own.
Of course, you need to ensure that the user's UID is unique for each user.
Related
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
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
1. The Context of the Problem
In my app, I'm creating a screen where the user could see other people's ranks. For that, inevitably, I'm going to need other users' names, profile pictures, etc. So, is there a way of querying that info through Firebase's authentication API? Or, for example, would I have to save that kind of data in a separate collection when the user logs in for the first time — doesn't sound like a good security practice to me.
2. How I think it would look like
I imagine the workflow would look a bit like this:
// ...
for (String userEmail in listOfUserEmailsInRanking){
UserInfo userData = FirebaseAuth.instance.getUserData(
email: userEmail
);
userDisplayName = userData.displayName;
userPhoto = userData.photoUrl;
// ...
}
My idea is that there should be some API following the example of displayName and photoUrl, which are both properties available from the FirebaseAuth.instance.currentUser() method.
It is not possible to use the Firebase Authentication client API to allow a user to query for other users. If you want to expose user account data to other users, you should write some code to write the required user data to a database, and query the database instead.
If you have concerns about security, and you're using a Firebase data (Realtime Database or Firestore) then look into using security rules to determine who can read and write its data.
Your second option can be implemented without compromising security. If you really intend to share some user data (which I suppose is not sensitive) you can create a shared separate collection of just that data and link it to the owner through some ID which you also keep in a private collection of that owner's properties.
Our current Firestore structure is as follows:
Currently we are not using any subcollections
Users have list of companies to which they belong
Every project is connected only with 1 company
Project belongs to a company, when in companyId field is written that company UID
My 1st question is how we can specify security rules defined by this database? Is there some best practice approach?
Our first idea was to do this:
match /databases/{database}/documents/projects/{projectUid}/{document=**} {
allow read: if
(/databases/$(database)/documents/projects/$(projectUid)/companyId) ===
(/databases/$(database)/documents/users/$(request.auth.uid)/companyId)
}
But according to the documentation this would mean that we would have for each read basically 3 reads (2 queries for security and 1 real read from DB). This seems like a waste of queries.
Is there a better approach than this?
We were thinking about changing to subcollections:
at the end we would have in root collections 'companies' and 'users' (to store all users details)
projects would be subcollection of companies
pages would be subcollection of projects
...etc
and companies would contain list of users (not the other way around like now) - but only list, not user details
This way we can use similar approach as from the doc, where each match would contain {companyId} and in allow statement we would use something like
match /databases/{database}/documents/companies/{companyId}/projects/{projectId} {
allow read: if
exists(/databases/$(database)/documents/companies/$(companyId)/users/$(request.auth.uid));
}
Thanks for any recommendations on how to build it in the most scalable and especially most secure way.
Have you considered adding a user's company ID as a custom claim to their profile? That way no additional reads are needed in your security rules.
Since setting these claims requires the Admin SDK, it will require that you can run trusted code somewhere. But if you don't have your own trusted environment yet, you could use Cloud Functions for that e.g. based on some other action like writes to your current Firestore structure.
Adding an answer to Frank.
Borrowing from other API SDKs such as microsoft graph, typically to make a resource request you start by initializing a Client object with an authentication token representing the scope/rights of the user. For example:
const client = new SDKClient(my_auth_token);
The client constructor would have a token validation step on claims. You can then make REST calls such as
const response = await client.someEndpoint({ method: 'POST', body: my_object });
I suggest rather than using the admin SDK for read/write to your firestore, you use the regular firebase nodejs client. To restrict access with security rules, pass a firebase JWT token into this custom SDKClient class with the token that you obtain from the header of your requests. In the constructor, initialize a new firebase 'app'. Because a regular firebase client is
subject to security rules, this will do what you're looking for.
Some example code has already been offered in this answer.
I should add that according to this firebase doc there is a 'warning' to use the admin-sdk server-side, but I'm not sure I see why.
One approach I've thought of for something similar that we are working on, that is, private chatrooms where only certain users have access, is to encrypt all messages with an on-server key, and only grant read access for that key to certain users. That way the extra read only has to occur one time, just when getting the key for the first time, then normal reads with no additional security rules are fine, as an attacker wouldn't be able to do anything with them since they are encrypted and they don't have access to the key.
I'm new to meteor and I've reading a lot however I'm a little confused around the meteor.users collection and the best way to use it. My interpretation of the best practice guide is that meteor.users collection should only be used for managing the accounts.ui package; email, password and username. The guide states that profile is insecure, a flaw in the original meteor design and should not be used.
So my question is, if I want to create a user profile that contains things like first name, last name, age, address, avatar etc do I create a separate collection like 'userProfile' and link it using the meteor.userid or am I suppose to keep it in the meteor.users collection somehow
Common practice is to put user profile information such as the kind you're describing into Meteor.user().profile. In fact people often do much more, for example memberships in groups, arrays of postIds, all kinds of things. Keeping a separate 1:1 profile collection is an option but there's no fundamental reason to do so that I can think of. On the contrary it makes things just a bit more complicated.
Update: As #jonatan points out in the comments, the Meteor Guide has now unrecommended the use of the profile field in the user document.
Instead they recommend storing custom user information as top-level keys in the user document. This is not only more secure but also more performant since incremental updates can get published over DDP on top-level keys but on sub-keys.
Meteor.user().profile is always auto-published for the current user even after the autopublish package has been removed. Information about other users is not published at all unless you explicitly setup a publication. In that case care must be taken to only publish those fields that should be visible to other users. For example you may only want to publish the usernames of other users and not their email addresses for privacy. You would do this with:
Meteor.publish('otherUsers',function(){
return Meteor.users.find({},{ fields: { 'profile.username': 1 }});
});
You might also restrict the set of other users that is published based on them being connected in some way to the current user to avoid publishing all users all the time.
You should also avoid publishing the services key which contains security information about the user (ex: the bcrypt of their password). As #David Weldon points out in the comments, you shouldn't put other security information in the profile either and you probably want a deny rule on the user modifying their own profile from the client.