- Overview
- Transcript
2.5 Registering Users: Creating the API Endpoint
We'll complete the user registration process by handling input from the client and processing it with our RESTful API.
1.Introduction2 lessons, 06:25
1.1Introduction01:18
1.2What You Need05:07
2.User Registration and Authentication7 lessons, 1:05:20
2.1Initializing the Client Project08:44
2.2Maintaining State With Vuex05:28
2.3Registering Users: Creating a Vuex Action09:31
2.4Setting Up the Server11:17
2.5Registering Users: Creating the API Endpoint12:43
2.6Authenticating User Credentials11:02
2.7Guarding Vue Routes06:35
3.Wireframing the UI3 lessons, 27:30
3.1Implementing the Feeds Panel06:45
3.2Showing the Articles08:44
3.3Creating the Settings View12:01
4.Handling Requests5 lessons, 39:24
4.1Writing Authentication Middleware06:33
4.2Fetching Feeds10:29
4.3Adding Feeds07:04
4.4Deleting Feeds07:28
4.5Fetching Individual Feeds07:50
5.Conclusion1 lesson, 01:04
5.1Conclusion01:04
2.5 Registering Users: Creating the API Endpoint
Before we can store data in the database, we need to create what's called a schema. This essentially tells the database the shape of the data that we want to store. If we were working with a relational database, this is very much like creating the tables and defining the columns that we wanna store except that we don't have tables and columns and rows and things like that we are working with a document database. So all of this information is gonna be in a single document and you will see what that means if you're new to document databases. So we're going to create a new folder called models, and inside of here we will create a new file called user.js, and we are going to need mongoose because this gives us the API for creating a schema. So after we require mongoose, we can get to the schema constructor function by just using mongoose that schema, and then we will simply define our schema. We're going to call this user schema. We will new up the schema constructor function, and then we pass in an object that describes our document. Now, it's very easy to think of a document as a JavaScript object, because especially as we view this in our database, it's going to look like a JavaScript object. So, start thinking in terms like this, because we can logically organize and store data together, and it's very nice way of working with this data. So the first thing that we need is our email address, this is our username. We're going to say that this is a string. We're also going to say that this is unique because it is the user name. So it does need to be unique and because it is unique, we don't have to specify that this is an index, this is going to automatically index for us, so we're got there. The next thing we need is the password, which is a string and it, because we only need to define password as a string we can leave it like this. We don't have to use an object, set type to string or anything like that. This is just a shorthand way of defining just a single property or a single value. The next thing that we're going to store are the feeds that a person subscribes to in a relational database, this would be in a completely separate table and then we would have a relation between the user and the feeds by using something like a linking table. We don't have to do that here. This is a single document that's going to have all of the information about this particular user. So our feeds, there's going to be an array and each item in the array is going to be an object with a URL property and that is going to be a string. So there we go, that is our user schema, very simple and straightforward. So now that we have a schema, what we want to do is create a model and we will do that by using the model method on our Mongoose object here. The first thing that we pass is the name of the model which is simply going to be users. This is essentially going to create the users table if you will in the database but it's not a table, it's a model. The next thing is the schema for that model, so we will pass in user schema there. And then we will simply export both of those things. We don't necessarily need both but in case if we need the schema someplace else then we can have access to that. We of course do need our user model because we're going to use the user model object in order to create our new users. And with that done, we can close that file and inside of auth, we are going to require user there. So let's go ahead and pull in that model. And of course, the path to that is in the parent directory models, and then user. And we'll go ahead and pull in everything else that we need. We need to bcrypt so that we can hash the password. And we also need the JWT, so let's pull that in as well, that is from Jason web token. All right, so with all of these things, we can finally register our user. So the very first thing we need, is access to what is coming in the request. So we have the email which we will get from the request body. And this is automatically given to us because in the previous lesson, we set up the middleware for parsing the body is Jason. So we are good to go here. And then we will need the same thing for password. So once again we're going to access that from the request body. Now, we do need to make sure that we have an email and a password. So we're going to check if we don't have an email, or if we don't have a password, then we of course, need to send back a response to the client that says you need to supply those values and we can do that very easily. We're going to use the 422 status that essentially means that it is an unprocessable entity. And that's very true we can't process this because we don't have one or both of the required fields. Then we're going to send a message and I'm gonna do it like this. We are gonna use JSON stringify then we're going to pass in an object that's going to have an air property and then as far as the message is concerned, please supply an email address and password. So that's going to be good enough in that case. Ideally what we would do is just return. Just a simple identifier like required registration or something like that and then the client would use that as a key in order to get our actual message there but this is going to be fun. All right, so if we do have an email address and a password then we want to hash our password and then store that in the database. So we can do that with bcrypt. Now there are two methods that we can use to hash the password. We can use hash sync which will hash it synchronously, or we can use just hash, which will be asynchronous. And that's what we're going to use because we want to be asynchronous. So we will pass in the password as the first argument. The second argument is going to be what is essentially going to auto generate the seed for this hash process. And you can see that this is the salt or rounds. So this is essentially going to give us eight rounds of salt for our hash. Now we could generate our own salt for this particular process, but the auto generate is going to be just fine. And because this is asynchronous, we do need a call back function here, so we're going to have either an error, or we're going to have the resulting hash. And we are going to use that resulting hash by calling the create method on our user model. And we need to supply the information such as the email address, as well as the hashed password. So we're going to say password, it's hash and that's it. We don't have any feeds yet, so we don't have to specify those feeds. Now, this too is an asynchronous operation, so we need a call back function as well. And if everything is okay, then we are going to have a user object at our disposal. But if not, then we're going to return an error, and let's just do a 400. That may not be really what we need to do in this particular case but for right now that's going to be fine. We will send the error and that's gonna be okay. Now if we get past this that means that we have a user object. And this also means that we need to generate our token. So let's create our token by using jwt.sign. And we're going to pass in the ID of this user that's going to ensure that we can find out what the user is through this bearer token because we need some way to determine what user is sending the request. Now this is where our secret value is going to come into play. So we're going to grab that from our process .env we will use the secret value there. And then we can also specify some options such as it expires in a certain amount of seconds. And if we use the value of 86,400, that is 24 hours worth of seconds. So that is going to be give us our token, so that then we can send back our token. And I don't know if we need to supply anything else but the token should be okay. So let's do a quick check, make sure that everything is okay before we actually test this, we are plugged in to express the router, the user, the bcrypts. Yeah, as far as our user model is concerned, we need user there that's kind of important so that we can actually create that user. So we are retrieving the email and the password. We are checking if we have those values and if not then we are simply returning some information. And really we don't need Jason stringify there, we can just pass in that object and that's going to be fine. All right, so then We bcrypt our password, we get the hash so that we can create that user. And if that is successful, then we return with our token. So everything should be okay there. Let's go to the browser let's just refresh for good measure, let's clear out all of the requests and then let's just try to create a user. So, I'm going to use password as my password and register and we have our two requests, both of which were successful. Now, the two requests I didn't explain this, did I? This is because of course, the first request is essentially an options request. This is finding out what is available for us to use. That's why we are seeing two and that's why it's normal. So It's normal, don't worry too much about that. As far as the actual requests that we are concerned with our post request that was successful. Let's look at the response and we have our token. That is wonderful. So that means that we should have information inside of our database. So let's go to collections them and we should be able to see our user model. And one thing that we forgot to do inside of the connection string is change the name of the database. And we could have done that we can go back to .env and that right there, my first database, we could have changed that to something else and something that would have been little more worthwhile, but this is going to be fine. We have our users and if we look at the documents inside of our users there we have our user we have an ID that is that object that we used to generate our jwt token. We have the email address and the password, which is hashed which is great. Then we have our feeds array which we don't have any feeds yet, but we will later on. So we have successfully we registered a user. What we need to do then is react to that in the client so that's when we register the user we just automatically redirect them to the feeds page, and we will get there. But in the next lesson, we need to provide the ability for users to log in