Now we've got our password manager class all put together.
We're going to make use of it inside of our user model file some inside of my model's directory look
at the user dot test file at the very top.
I'm going to import password from of one directory services password.
Now whenever we tried to save a user to our database we're going to implement some code inside of here
that's going to automatically intercept that save attempt.
It's going to take the user's password that we've set on the user document hash it and then overwrite
the password on the document so let's put this together down towards the bottom to file right after
we build out our user schema.
I'm going to add in a new method right after that we will say user schema not pre save.
So this is a middleware function implemented in mongoose.
Anytime we attempt to save a document to our database we are going to execute this function right here
immediately.
You will notice that I marked this function as async Mongoose very similar to express is kind of in
the old way of doing things Mongoose does not really have great support out of the box for async await
syntax instead to handle any kind of asynchronous code that we want to run inside this little callback
function we get this done argument.
So we are responsible for calling done once we have done all the work we need to do inside of here rather
than just saying oh wait.
Blah blah blah something and then letting Mongoose figure out what's going on.
We have to do our a wait call.
Anything else we want to do.
And then at the very end we have to call dun
you'll also notice I defined this function using these function keyword as opposed to an aero function
like this right here.
So a quick reminder whenever we put together a middleware function we get access to the document that
is being saved.
So the actual user that we're trying to persist to the database as this inside of this function if we
used an arrow function right here then the value of this inside the function would be overridden and
would be actually instead equal to the context of this entire file as opposed to our user documents
not what we want.
So that's why we are using the function keyword instead of the arrow function so inside of here we're
gonna do two quick things we're gonna check and see if the user or me we're gonna check and see if we've
modified the user's password we're gonna say if this dot is modified
the reason for this is that we might be retrieving the user out of the database and then trying to save
them back into the database at some future point in time we don't have any functionality around that
just right now.
Let's imagine that we had some kind of email changed functionality that would involve us fetching a
user out of the database changing the email and then trying to save it to the database.
So in that scenario we would still be running this middleware right here if we only changed the email
we would not want to tried to rehash the password or anything like that because that means that we would
be hashing a already hashed password.
Definitely not what we want.
So we are only going to attempt to hash the password if it has been modified when we first create a
user and assign a password to them.
So in other words when we eventually write out something like user dot build and throw in an email and
a password this would mongoose will consider password to be modified.
So even if we are just creating this thing for the very first time is modified password it will return
true.
All right.
So instead of here we're going to get the hashed version of the password.
So we'll do it in a weight password dot to hash and we will pass in the user's password that they just
set or that we just set on the user documents it will say this dot gets
that's going to get the user's password off the documents and we'll pass it into two hash.
And that gives us back the hash password.
Well then go ahead and update the password.
So this dot set password to whatever we just got back out of the password hashing function.
And then finally after the if statement we'll call done because we've now done all the asynchronous
work we need to do.
All right.
That looks pretty good.
I'm going to save this.
Let's now go ahead and attempt to test this out by signing up for a new account.
Remember right now any time we sign up for an account or sign up as a user our root handler back inside
of sign up dot T.S. takes the newly saved user and sends it back to whoever made the request right now
or previously when we were trying to test this thing out we saw that we sent back the password in plain
text.
So now when we send back this user we should see the password in a hashed format instead.
All right.
So I can go to post.
I'm going to put in another unique email address.
I'm going to send this in and there we go.
So I can now see that the user that gets sent back to me I've got my email and I've got a hashed password
on there as well.
Now looks good to now we are no longer storing passwords in plain text inside of our database.
That is fantastic.
Now we still have to put together some logic to actually do the password comparison.
We're going to write that out during our actual sign in implementation so we're just about done with
the sign up stuff.
The last thing we have to do as you will recall is make sure whereas it whereas it whereas it back over
here after we have saved the user to the database we are now considering this person to be logged in.
So we need to figure out how we're going to actually consider a person be logged in.
We need to figure out whether we want to use a cookie.
Jason web token or whatever else.
Let's figure all that stuff out.
Starting in just a moment.