All right, and essentially why we're getting that error in the previous video.
Remember before we comment about the code?
And before we take a look at the functionality that caused that, let's also discuss the fact that not
every method will trigger this hook.
This is very, very important where if, for example, if I were to go with find one and update, everything
would have worked out fine.
We basically would have bypassed the stock and we would be on our way already, or I purposely wanted
use their debt save to showcase that there's going to be some methods that will trigger the silk.
And in the process, we need to take a look at what is the approach, if that is the case.
Essentially, that is the point of this video.
So hopefully that is clear and that's why we purposely went with this user.
That same now next why there was this error.
Well, because if we take a look at the script hash out, we're looking for this that password.
Now remember, like we already previously talked about in the user, select password is equal to false.
And in the off controller, when we use this fine one, we don't return the password.
So when I go here with users, save will trigger the hook.
Now what are we doing in the hook?
We have b crypt hash and then we're looking for this dot password.
But since we have set up the password equal to select false, therefore this one will be undefined.
And technically you can look at it and you're like, OK, well, we'll do the same thing.
We're going to go over here with select and add the password.
But what we also need to understand that if that is going to be the case, why do you think it's going
to be a result?
So if actually I do have the password, essentially if I go with that select and then plus the password.
And if I hash it, don't you think that I'll essentially hash the password that is already hashed and
in the process, my log in is going to be messed up because now when I'm trying to log in with secret,
which essentially is my password now, it won't match to the hashed value in the database.
And I'm not going to show you the example because it will take some time to set this one up.
But yes, what you need to keep in mind if you go here and you add this password and essentially this
functionality will work as expected that as a result, your in functionality won't work because in that
case, you'll hash the password for the second time that is already stored and hashed in a database.
Now what is the solution for both of the scenarios?
Well, the solution is following where we can go with this and then modify paths so we can check which
paths are we modifying and what supernovas we can look for.
Specific one.
And if we're not modifying the password, which our route is not doing, essentially we want to modify
everything else but the password.
Then we simply return and in the process isn't going to do two things.
First, where we won't get this error when the password is not provided.
And second, if this not password actually exists in the instance, then you won't hash it for a second
time.
Hopefully, this makes sense and now not set it up in the user dress.
Let's navigate there.
I mean, at the moment, I have commented them out and what we simply want to do is go and log.
And we can go off this dot and then we have this method that returns all the paths that we're modifying.
So let's invoke it and let's go to the postman and let's send one more time.
So in this case, I'm just going to send it as it is.
And what you'll notice that at the moment, we're technically have an empty array, correct, so we're
not modifying anything.
But if I go here and then say that name again is going to be John, but notice now I have name here.
And effectively, this function just returns nicely.
Which values are we updating?
And hopefully you can clearly see that it only returns values that are different to the ones that we
already have in the database.
So hopefully that is square.
And like I said, there's also this there's not and then is modified so I can check for specific path.
And if I'm modifying that one, well, I can do something based on that.
And in our case, we actually will look for is modified land password.
And if we're not modifying the password, well, I don't want to do anything there because you're in
now.
If you took mine, of course, that if we're modifying the password, then we're setting everything
from scratch anyway.
But in this case, since I don't want to touch the password, I don't want to get the error or I don't
want to hash it for the second time, and therefore I just want to return from the function.
So let me go back to the user one.
I'm not going to log it.
I mean, if you want, you can definitely do so.
In my case, I'm just going to set up deconditioned.
First of all, I'll comment out of this one over here and I'll say, if this and then that and is modified.
So if I'm not modifying which field, well, the password field, if we're not modifying that, then
I want to go with a return over here.
Then we can uncomment the previous set up because we will use it once we save.
And then if I go back to the postman and if I try to send it, you'll notice that everything will work
as expected.
Can I send it and I get back beta and yes, when we're talking about of the register functionality.
So essentially, when we registered user, this will be still correct.
Where we'll still hash the password as we should.
And once we have this in place now, we're finally ready for the front that.