All right, so our functionality works like Peaches.
However, there is a tiny gotcha.
You see, if we take a look at our validation middleware over here.
More specifically, I'm looking for validate ID param.
Notice how we're only checking for two things.
We're checking whether the mongo id coming from the params is a valid one.
And also we're checking whether the job exists, but we're not checking whether.
The user who is making the request is the actual owner of the job.
So what am I talking about?
Well, if we navigate back to a thunder client again, I'm going to look for get all jobs.
I'm assuming that this is going to be John.
So this is the ID, Let me grab it over here.
And then if I go to a single job, everything should be correct.
We'll still have access to this one single job.
But the problem is that Peter, with the same ID, can access the job.
Not only he can access the job, but he can also modify it.
He can also delete.
And that's probably not the best setup.
So let me just showcase that.
Let me go back to login.
And here I'm going to go with Peter.
And now I'm logged in as Peter.
I clearly can see that if I take a look at the jobs, this is the Facebook one.
So the owner, of course, is Peter.
However.
If we take a look at the single job and notice I'm still keeping the same ID, the created by value
is going to be different.
So that means that.
I can still access someone else's job.
And that's not the behavior we want in our application.
So we also want to check whether the user is the actual owner of that job.
And in the process, we'll also check whether our user is admin.
And if that's the case, then of course we'll still allow access to the specific resource.
So we want to go back over here to validation middleware, more specifically validate ID param and I
just want to showcase something pretty, pretty cool.
So if we go with value, then add comma and then object, we actually have access to the request.
So again, for now let's just log and you know, yeah, let's go with the entire request.
So.
It doesn't really matter.
Which user we're using for now, let me just go back to single job.
And again, I'm looking for the console and notice I have access, of course, to the entire object.
Now, what am I looking for?
Well, first of all, I want to grab this user ID and also I want to grab the role.
And then remember, if we get to this point in this middleware, basically if the job exists, then
also if we log we'll see the created by.
So let me just do it.
Just so you don't think that I'm messing with you again.
We're looking for get a single job and check it out.
If I scroll down, I have a bunch of properties over here, but the one that I'm looking for is created
by now one.
Gotcha.
This is not a string, so we'll have to turn this into a string.
Now, why am I mentioning that?
Well, because if you remember, when it comes to a user, this is right away string.
And we can clearly see that in the console.
So effectively I want to compare these values and only if they match.
Basically, if the job belongs to the specific user, then we want to proceed.
Hopefully that is clear.
So now let's remove all of the logs and let's set up the logic.
So first of all, I want to check whether the user who's making this request is an admin.
If he or she is an admin, then of course there is no issue.
The way we'll do that, we'll just set up a property.
I'll say is admin.
Then it's located in rec dot user.
Again, we have access to entire object and in there we have the user object.
And in here I'll just check if it's an admin.
So if it's an admin, no issues.
And also we want to check if the user is an owner of the specific resource.
In this case, of course job and the way we can check that is rec dot user user id remember it's a string
and we want to compare it to job created by, but we want to turn this into a string as well.
Otherwise it's going to be false.
I can tell you that right away.
So let's set up these two variables.
And now I just want to set up a condition.
I'll say if the user who's making a request is not an admin or not an owner, this is where we want
to throw another error.
So I'll say if not admin and if not owner now what error do we want to throw?
Well, we want to go with unauthorized error, which is 403.
So let's go over here with throw.
A new and we want to import on authorized error.
And as far as the string we'll just go with not authorized to access this route.
Okay, good.
But if you remember from the previous errors, essentially you will be sending back 400 unless we add
a condition here in the with valid errors.
So let's navigate back over here and essentially right after no job we want to go with if and again,
we're looking for error messages.
The first one over here and let's just go again with starts with and let's pick.
August.
The first two words over here.
Let me set up over here as a string.
And as far as the actual condition.
We want to take the same thing pretty much again.
Keep in mind that you can just throw regular JavaScript error.
The result is going to be exactly the same.
So now we have one for node job and not authorized.
So now if everything is correct.
I shouldn't be able to see the job.
So notice now I'm getting back 403 and I'm not authorized to access this route.
Now, of course, if I'm going to go back and if I'm going to log in.
As John.
Then we should have no issues, correct?
We're going to get single job.
And of course, we can modify the job, delete the job and all that cool stuff.
And with this in place, we can move on to the next step.
A quick update.
While I was recording a video, I made a tiny mistake in the condition we want to use and operator not
or.
So we throw an error.
If the user is not an admin user and not an owner of the job.
So again, we want to use and operator in this condition.