- [Instructor] Did you figure it out?
Well, let's look at the routes again.
So I'm heading into API to do list index chairs.
And there we have this update route.
We know that everything on the slash to do list is protected
by a password. So if you look into index chairs,
we see that down here where we have a mount
slash to-do list, you're using passport authenticate.
So there is no doubt that the user that ends up with their
request on the slash API slash to-do list
has a valid JWT token.
And from then on, we trust the user blindly.
So everyone that has an account must be a good person
because the update and the delete route,
delete or update an item without even checking if this item
belongs to the user.
So let's look at the portrait again.
So we get this item ID,
and then we just do this update
by providing the item ID that we got by request arguments,
and we send the body with the data that should be updated.
And the same is true for the delete route.
So if I know the object ID I can do
basically anything with this object, granted in our case,
it would be hard to guess this object ID,
but maybe we provide a way to
view to do list items of other users.
And there we leak out the object ID
through the API or, and it happens so often,
we are just using ascending integers as the item ID.
Then I can just use a script and send
delete request to all items in the database,
if I just have a valid user.
So that's bad, we need so-called object level authorization.
We need to make sure that an object that we manipulate
really belongs to the user that is currently logged in.
In our case, this can be done with a simple fix.
So what I'm doing now is I'm adding
an argument to update item,
and this is request dot user dot ID.
And I do the same for the delete request.
I'm also adding request user ID as the first argument.
Now I'm heading into the to do list service
and there I add now this argument and it's the user ID and
also for delete it's the user ID, and now what I'm doing,
and that's rather trivial. I'm not just adding user ID.
So that's the shortcut. You could also write user ID, colon,
user ID, but that's the same.
So we can just leave the property here as a find argument.
So now the query really tries to find an object that has
the ID that is provided and also the user ID that I provide.
So with that, there is no chance
that I can access the object if I don't
have the user ID with me,
and I only can provide this user ID,
if I'm actually logged in.
The same, I do now for delete item.
So I'm also updating it here to add the user ID and with
that our items should be protected now.
And let's try this out in the browser.
So let's click on this item. You see, it's crossed out,
let's click on it again and it's updated again.
So let's change, go fishing into go hiking,
and I can still do this.
So now everything is still working,
but I can be sure that no user accesses an item that
don't belong to them.
So when implementing APIs,
you should always look out for such security holes.
They are so common and really cause a lot of trouble.
With that, our, to do list application is done
and you can stop the app
because we won't need it any longer.
In the next chapter,
we will focus on a very popular aspect of authentication,
it's single or social sign-on.
We want to make it super easy for our users to sign into our
application and so we let them use
an existing account from another site.
Also here, passport will simplify things, dramatically.