View the Signup and Login Endpoints
Ryan Chenkie: [0:00] Before we get started with the login and signup functionality from the React app, let's just take a quick look into what's going on on the server when we go to log in or sign up.
[0:10] Come into orbit-api and go to server.js. Let's take a look first at the signup endpoint down here. Let's scroll down to where we see api/signup.
[0:22] Just a quick tour of this endpoint, we're taking a few things from the request body, email, first name, and last name, particulars about the user that are going to be part of their user record. Likewise, we are taking the password that they supply when they sign up as well.
[0:36] We can't just take the password that they provide us and put that in the database itself because that would be putting our passwords in the database in the clear. That is absolutely a bad practice. We should not be storing passwords in the clear. Instead, we are hashing our passwords.
[0:51] We've got this hash password function here which goes to this util spot that we've got. Within util in hash password, we are taking the password in and then using Bcrypt to generate a password hash. The passwords are both hashed, and they are salted. Here, we've got genSalt with a strength of 12. We are salting and hashing our passwords.
[1:15] Back over at the signup endpoint, after we get a hash password, we are going to put that into our user data along with the other items that we've got from our user.
[1:26] We'll first check if there is an existing email address that the user supplies in our database because we don't want to have two users with the same email address. If there is an existing email, we just send back a 400 error saying the email already exists.
[1:40] One thing to note here is that some people argue that you shouldn't send back a message like the email already exists. That means that if people are wanting to snoop around, they might go to the signup form and just put in the email addresses of people they're interested in to see if they have an account already. Some people consider this somewhat of a privacy concern.
[1:59] My take on it is that we want to be able to provide a clear message to the user about what's going wrong. In this case, we need to say that that email address already exists. Otherwise, it's just going to lead to user frustration.
[2:12] You'll see that if you sign up for services like Gmail or Twitter, they're going to give you this kind of message anyway. It is at least something that large companies are doing.
[2:21] If the user does not already exist, then we are going to save that new user. Once saved, we will create a JSON Web Token for them, grab the expiry time for it, and then take all of that info and put it into a return object.
[2:35] In this return object, we've got message of user created. Then, we've got their token as an artifact of signing up, their user info, and the time that the token expires. Below, just some error handling.
[2:47] We've got something similar going on when the user goes to log in. That's found here at api/authenticate. In this case, it's a little bit simpler. We just take the email and the password from the user and then we are going to go to our database, find that user by email. If they don't exist, we say that they've got the wrong email or password.
[3:06] I'm of the opinion that for this particular message, it's important that we don't be so specific here. If an attacker is trying to break into our users' accounts, we want to give them as few clues as possible.
[3:18] Being vague about whether it was the email or the password that they got wrong is probably a good idea. That way, they aren't able to focus their efforts on one or the other.
[3:27] Next, we will call verifyPassword, and verifyPassword takes the user's supplied password and the password that we already saved for the user. This function delegates to something that comes from Bcrypt. That allows us to verify the user's supplied password with what we have saved for them.
[3:43] If the password is valid, we are going to take the info for the user, create a token from that and just like we did in the signup route, we're going to get the expiry, and then send back that information along with a success message in the return. Of course, if we get any errors, we will handle them down below.
[0:10] Come into orbit-api and go to server.js. Let's take a look first at the signup endpoint down here. Let's scroll down to where we see api/signup.
[0:22] Just a quick tour of this endpoint, we're taking a few things from the request body, email, first name, and last name, particulars about the user that are going to be part of their user record. Likewise, we are taking the password that they supply when they sign up as well.
[0:36] We can't just take the password that they provide us and put that in the database itself because that would be putting our passwords in the database in the clear. That is absolutely a bad practice. We should not be storing passwords in the clear. Instead, we are hashing our passwords.
[0:51] We've got this hash password function here which goes to this util spot that we've got. Within util in hash password, we are taking the password in and then using Bcrypt to generate a password hash. The passwords are both hashed, and they are salted. Here, we've got genSalt with a strength of 12. We are salting and hashing our passwords.
[1:15] Back over at the signup endpoint, after we get a hash password, we are going to put that into our user data along with the other items that we've got from our user.
[1:26] We'll first check if there is an existing email address that the user supplies in our database because we don't want to have two users with the same email address. If there is an existing email, we just send back a 400 error saying the email already exists.
[1:40] One thing to note here is that some people argue that you shouldn't send back a message like the email already exists. That means that if people are wanting to snoop around, they might go to the signup form and just put in the email addresses of people they're interested in to see if they have an account already. Some people consider this somewhat of a privacy concern.
[1:59] My take on it is that we want to be able to provide a clear message to the user about what's going wrong. In this case, we need to say that that email address already exists. Otherwise, it's just going to lead to user frustration.
[2:12] You'll see that if you sign up for services like Gmail or Twitter, they're going to give you this kind of message anyway. It is at least something that large companies are doing.
[2:21] If the user does not already exist, then we are going to save that new user. Once saved, we will create a JSON Web Token for them, grab the expiry time for it, and then take all of that info and put it into a return object.
[2:35] In this return object, we've got message of user created. Then, we've got their token as an artifact of signing up, their user info, and the time that the token expires. Below, just some error handling.
[2:47] We've got something similar going on when the user goes to log in. That's found here at api/authenticate. In this case, it's a little bit simpler. We just take the email and the password from the user and then we are going to go to our database, find that user by email. If they don't exist, we say that they've got the wrong email or password.
[3:06] I'm of the opinion that for this particular message, it's important that we don't be so specific here. If an attacker is trying to break into our users' accounts, we want to give them as few clues as possible.
[3:18] Being vague about whether it was the email or the password that they got wrong is probably a good idea. That way, they aren't able to focus their efforts on one or the other.
[3:27] Next, we will call verifyPassword, and verifyPassword takes the user's supplied password and the password that we already saved for the user. This function delegates to something that comes from Bcrypt. That allows us to verify the user's supplied password with what we have saved for them.
[3:43] If the password is valid, we are going to take the info for the user, create a token from that and just like we did in the signup route, we're going to get the expiry, and then send back that information along with a success message in the return. Of course, if we get any errors, we will handle them down below.