This article is about managing logins and registrations on an application using Firebase Authentication. Isn’t that funny?
Making a whole article just to talk about how to let a user create an account to our application or let them log in with Firebase Authentication should not happen. For many this seems to be the easiest part of the Firebase documentation, maybe they are right 🤷♂️.
Believe me, as simple as it may be, many developers run into problems when it comes to checking if the user already exists in Firebase to avoid conflicts about the two supposedly separate accounts. This is where several practices are used to get around this problem and not all of them are recommendable in my opinion.
I myself, who is writing this article, had encountered the same problem and some of the answers I found on Google did not please me so I am writing this article hoping to offer you an optimal solution based on the documentation of Firebase itself.
How to solve it?
There are two flows that I have seen on the internet to solve this problem, one that I call the worst and the other the finest. I will explain them to you in the following lines by presenting you the method I advise you against and the one I urge you to use when you are confronted with this problem.
a. Check if the user is in Firestore (Bad Tip)
In the case of the login, the solution recommends connecting the user by collecting his email via the form to check it in Firestore; if it exists, we connect him via Firebase Auth in the opposite case, we ask him to create an account.
In the case of registration, the user’s email is retrieved once again and checked in Firestore; if it is not there, the account is created; if it is, the user is told that the email is already registered and that he/she should either use another email or login.
This will certainly pass, but it causes three concerns:
You will be charged for this reading when it is unnecessary
An unnecessary reading requires more patience than most users don’t have.
- Bad management of the connection and registration when you should use a Single Sign-On like connecting with Google; because you won’t be able to have access to the email address before the user logs in and chooses his connection method.
b. Consult Auth, he is the solution! (Good tip)
For both login and signup, use Firebase authentication directly. In this part, I will present you step by step what should be done for good authentication management.
For a good presentation, I will develop an application for the purpose of the case. The application will be developed in :
AngularFire(7.0.4) which is the official Angular library for Firebase.
To make it easier for us to understand, I will divide the resolution into three essential phases: Signup, Login and LoginWithProvider (Google in this case). I encourage you to read the Angular and AngularFire documentations via the given links to familiarise yourself with them.
Install AngularFire on your computer by doing
npm i @angular/firebut to add it to your project you will need to do
ng add @angular/fire
The initialization of AngularFire in the project is done through the integration of AngularFireModule :
AngularFireModule.initializeApp(environment.firebase) and for the example, I added AngularFireAuth and AngularFireAuthGuard for authentication.
I have created a service that allows us to implement the different features we need for the example we have here.
A little beauty in this topic with the code below
b.1. SignUp (With Email)
Here is the HTML code of the page, the style is found globally in the code above (style.css)
To manage the registration with an email and a password, it would be enough to take the two parameters and then execute the createUserWithEmailAndPassword method. A promise will be returned:
1️⃣ In case of success: you redirect the user to the desired page; for us, it is the home page.
2️⃣ In case of error: you have four options
weak-password. These four possibilities also give you freedom of action in your code.
b.2.Login (With Email)
Here is the html code of the page, the style is found globally in the code above (style.css)
To manage the connection this time with an email and a password, it would be enough to take the two parameters and then execute the method signInWithEmailAndPassword. A promise will be returned:
1️⃣ In case of success: you redirect the user once again to the desired page; for us, this is the home page.
2️⃣ In case of error: you have four options
user-not-found and wrong-password. These four possibilities give you a free range of actions in your code.
b.3. Login With Provider
As for connecting to a Firebase provider like Google in this case, you have to be very careful. You will first have to implement the method that allows you to access the provider, then call it via your button; after the connection don’t hesitate to do what you want.
But this action can generate two mistakes: login as a new user when you already exist or login as an old user when he is a new user.
To solve this, it would be enough to check the connected user. Firebase returns login metadata, so you can compare the date of creation of the account and the date of the last login; if they are equal, it is a new user and if not, this user already exists in Firebase Authentication.
Note : The code for this part can be found in the two previous ones
I could not conclude this article by talking about a major element that in my opinion causes this concern. Authentication and Firestore should not be confused, the latter allows to store data after authenticating these users. Of course, we use the same uid to link the authenticated user and the rest of the data that we put in Firestore; we should understand that no user should be in Firestore without having been authenticated.
If you want to see the source code more closely, it is available at the following link.