Know that there's a relationship set up between users and tasks.
In this video we'll be heading over to the task router to add authentication to those final four task
related end points.
We're going to do some together and some will be your challenge for the video.
So to kick things off we're actually going to skip the second one where you fetch all tasks and we're
going to start with the third one where you fetch a task by I.D..
Now we still want to do just that.
I want the user to be able to fetch a task by I.D. But first I'm going to make sure they're authenticated.
And second I'm going to make sure that the task they're trying to fetch was a task they actually created
to get started as you probably expected.
We're simply going to add to the off middleware into the mix and that's going to give us an easy win.
The next thing we need to do is to change how we're fetching the task down below.
We're fetching it by I.D. Now we are still going to take the I.D. into account but we also need to take
into account the value for the owner field.
I need to make sure that lines up with the authenticated users user I.D..
So right here that means we have to change how we're fetching the task find my I.D. won't let us limit
by multiple fields.
We can just use find one to get that done.
So right here const task equals I'll use a wait with a task dot find one to find a single task.
And here we pass in that object where we can specify as many or as few things as we want.
For example I can filter by I.D. here using the shorthand sense I have a variable with the same name
and I can also go ahead and filter by the owner value and the value I'm looking for an owner is whatever
is stored under request dot user ID dot underscore I.D..
So here I'm just using the idea of the authenticated user.
So now I'll only be able to get the details of a task if I'm logged in.
And the task I'm fetching is a task I've created now that we have this in place we can remove the old
line and we're actually done.
If I'm not the owner or the I.D. doesn't line up I won't get anything back and I'll get a 4 0 4 as the
return value which is appropriate.
So there's no need to say something like this task exists but you don't own it.
That's giving away more information than you probably want to.
It's simply good enough to say for 0 4 if those two things don't match up with any tasks in the database
now that we have this in place let's go ahead and test it out to make sure it works as expected.
Now for the moment we only have one user and they have a couple of tasks in order to make sure all of
this is working.
We shouldn't get a second user into the mix and have them create their own tasks.
And just so we can make sure that our access control is actually functional.
So over in post man what does that really mean.
It means we're going to create a second user over here.
We have the data for the first user we've created.
We can just switch this up to something else.
I'll go ahead and use Mike at example dot com and I will use Mike as the name up above.
And then I'm going to fire that off to create the second user and I'll automatically be logged in as
them.
Then all I'm going to do is revert those changes back to what they were before.
So now we're logged in as that second user and we're going to do is create a couple of tasks for them
as well.
So we'll have two users in total each with two tasks.
Right here I'll go ahead and say something specific to Mike.
Let's just say Mike has something to do and I'll go ahead and change the completed value for this over
to true.
I can fire that off and make sure it's created successfully which it is down below.
Then we can add another one I'll leave completed off.
So it will default to false.
And right here I can say something like find a new job I'll send that off as well to create the second
task.
Now let's go ahead and try to find our task by I.D. I'm going to copy the idea of that task to the clipboard
and I'm gonna head over to the read task and point right here I have that showing up all I need to do
is swap out the I.D. up above with the I.D. I just copy to the clipboard and I should now be able to
fire this off successfully.
I'm gonna send it off and what do I get.
I get my task showing up now.
This is testing that things are working.
When I'm logged in as the user and I'm fetching a task that I do own let's make sure that I can't fetch
this task if I'm logged in as the other user.
So now we're going to log in as that first user once again over here for log in user.
I have that data from earlier in the class I log in as that first user head back over to the read task
request and try to fire off the exact same request.
The only thing that's changed is now on user 1 instead of User 2.
And I'm not the one who created this.
If I fire that off what do I get.
I get a 4 0 4 which is fantastic.
So users can pull their tasks by I.D. if they created them and you can't pull a task by I.D. even if
you're authenticated.
If you were not the person who created it.
So that is all we needed to change for this router.
Right here we added the author middleware and we tweaked one line of code.
Now we're going to end up doing the same thing for the other routes in this file.
There are three others and we'll start with get tasks right here.
Now getting this done is going to be your challenge for the video and I have some challenge comments
to outline what I'd like you to do though the process is basically identical to what we did down below.
The first thing you're going to do is add authentication to the end point and from there you're going
to change which tasks we return.
Right now we would end up sending back both users for tasks even though each of them only have two associated
with their account.
So we want to take the authenticated user I.D. into account when finding the tasks we want to limit
by the owner.
Now there are two ways to do that.
We could modify the task dot find call to search for the owner inside of here or we could use the populate
functionality we explored in the last video to get all of the tasks for a specific user.
Either way would work from there.
Test your work.
Make sure that you can only see the tasks created by that specific user when firing the request off
over in post man pause the video knock that out.
And when you're done come back and click play
how that go.
Let's go ahead and kick things off by adding authentication into the mix.
So right here we will set up the off middleware and from there we'll be able to go ahead and modify
the line down below.
Now there's two approaches you could have taken.
One would be to change what we provide as the object argument.
We would set up owner and the value we'd be looking for is on request.
User dot underscore I.D..
This would 100 percent get the job done.
I'll also show you the alternative which would be to do the following right here.
I would use a wait with request dot user.
Now here what I'm going to do is populate their tasks.
So dot populate populating the tasks exactly like we did in the last video then we just call the function
we've used before.
E X E C populate.
This would also work just as well.
And then down below we would just send back request user Doc tasks.
So either approach is gonna get the job done as long as the end point works as expected then your solution
is valid up above.
I'll remove those challenge comments and we can test things out over and post man.
I'll save the task router over in post man.
We can move over to the Reid tasks.
End Point here I'll fire them off while logged in as that first user and I can see the tax we created
for them.
I don't see that task about Mike and I don't see the task about getting a new job because those were
created by the second user and I'm authenticated as the first user so I only see the two tasks.
This one actually created now that that end point is all wrapped up.
We can continue down the list.
We already knocked out this one and the next one we have right here is the ability to update a task
by IDC and we're gonna end up working through a similar process to the other two.
Now this one will work through together.
Let's start by adding authentication in and down below.
We're gonna go ahead and switch how things work.
Right now we are finding the task by I.D. which we don't want to do.
We want to find it by I.D. but also by the owner value.
So const task equals a weight.
We are going to await a call to task.
Find one.
We're going to find it by its I.D. we get that value exactly where we were getting it before that is
and request dot paradigms dot I.D. and also owner and owner is going to be request dot user dot underscore
I.D..
Perfect.
So now we're finding the task by a way that takes the owner into account.
Now right here we're actually trying to update the task before we even know if it exists.
All I'm going to do is take these two lines and move them below the if statement.
So now we'll have that for all for print.
If no task is found either because it doesn't exist by the I.D. or you're not the creator.
So now that we have this in place let's go ahead and test our work and make sure we can update our tasks
and that we can't update someone else's tasks.
So over and post man I'm logged in as that first user and I have a couple of tasks right here I'm going
to go ahead and grab the I.D. for the second one go to office and I'm going to try to update it.
So right here I'll grab that I.D. I'll head over to update task and paste that in the U.R.L..
Now here.
I will switch up the completed value so if I go back to read it tasks we can see it was false it was
not completed over here.
I will adjust that over to true.
I'm going to fire off the request down below I get a two hundred and I can see the updated task go to
office is now completed from here what I'm gonna do is try to update a task that I did not create.
So to do this we could log in as that second user and grab one of those task ideas or we could do that
from over in the database which is the approach I'll take I'll go over to the tasks collection and refresh
things and here.
The second two those belong to the other user.
So I'm going to right click one of them and edit it just so I can copy its I.D. to the clipboard.
Here we have the task that Mike created.
Find a new job.
Once I have that I.D. I can head back over to postmen and pasted in up above.
Now I'm still logged in as that first user I should not be able to update this task down below.
I fire that off and what do I get.
I get a floral for showing up which is fantastic.
So now all of the routes are converted except for the final one which is the route for deleting a task
by I.D. right here.
This is gonna be your second challenge for the video.
So what are you going to do.
You're gonna do the same sort of thing we've done three times already.
You're gonna add authentication you're going to make sure that when you delete the task you're taking
the owner into account as well.
Right here we have find one and delete which can allow you to get that done.
Similar to how we used.
Find one up above.
Then you're going to test your work tried to delete a task that you've created.
It should work.
Then try to delete a task created by another user.
And that should fail take some time to knock this out.
Test your work and when you're done come back and click play
how'd that go.
Let's go ahead and kick things off by adding authentication into the mix.
I'm gonna get that done right here by setting up the off middleware then down below we have to update
how we are finding the task.
This approach is no longer going to work as it only takes the task I.D. into account.
Instead we want to take task I.D. and the owner value so const task equals.
I'll use a wait with task dot find one and delete.
Which is very similar to find by I.D. and delete though we can provide an object like we do with find
one to specify the criteria we're using for searching here.
The underscore I.D. field needs to have the following value which comes from request dot paradigms dot
I.D. and the owner needs to line up with the I.D. of the authenticated user request dot user dot underscore
I.D..
Perfect.
That's all we had to do in order to get this done.
So let's go ahead and remove the other line.
We will remove the challenge comments save the program and now we're going to test things out.
Now over here I already have an I.D. of a task that I did not create.
I used that to make sure that updating failed.
I'm going to start by making sure deleting fails since I already have this idea available.
So over here for a delete task I will try to delete the task that I also could not update.
It should not work here either.
I'll fire that off and what do I get.
I get a 4 0 4 now if I head back over to read tasks I can see the tasks that I do have control over
and I'm going to delete the second one by its I.D. so I'll copy the idea to the clipboard head over
to delete task.
And from here we're just going to paste it up top.
I fire this off and this time it should work.
And right here it did.
I have a two hundred and I can see the deleted task if I were to request all of my tasks again I would
expect to just have one and that is exactly what I get.
I no longer have to go to the office but I still have to finish this node course.
So with this in place all of the task routes they require authentication and they also take that into
account when it comes to the relationship between you.
The authenticated user and the task you're trying to work with.
When you create a task it's associated with your user and whenever you try to read a task update a task
or delete a task we make sure it's a task that you actually created.
All right with this in place there's only one more thing I want to cover in this section and that is
coming up next we're gonna talk about how we can delete the tasks for a user who's deleted themselves.
So if I close down my user profile I would expect all of my tasks to go away as well.
We'll knock that out.
Coming up next.