‫So after updating, let's now also allow the current user
‫to basically delete his account.
‫Now when a user decides to delete his account,
‫we actually do not delete that document from the database.
‫But instead we actually just set the account to inactive.
‫So that the user might at some point in the future
‫reactivate the account and also so that we still
‫can basically access the account in the future,
‫even if officially, let's say it has been deleted.
‫Okay?
‫So to implement this, first of all
‫we need to create a new property in our schema.
‫So,
‫let's go there.
‫And now we want to have
‫a field called active.
‫Okay.
‫Which should be of the type
‫Boolean.
‫Okay, and by default
‫it's gonna be
‫true.
‫So any user that is created new
‫is of course an active user
‫and so the Boolean is set to true.
‫Also, we do not want to show this in the output, okay.
‫Because we basically want to hide
‫this implementation detail from the user.
‫Okay?
‫And so we don't want anyone to know
‫that this flag, so this active flag is here, okay.
‫So we say select, and set it to false, all right.
‫And so,
‫to delete the user now,
‫all we need to do is basically set
‫that active flag to false.
‫Okay.
‫So let's create that function here,
‫exports
‫.deleteMe,
‫so it was updateMe
‫and now it's deleteMe
‫and so we already know that we're using
‫a catchAsync here, right?
‫And then Async because we basically already know
‫that we're gonna update the user.
‫So request responds
‫next.
‫So, await
‫User.find
‫by ID and update.
‫Okay, and again, of course there's only works
‫for logged in users and so the user ID is
‫conveniently stored at request
‫.user.id.
‫and the data that we want to update
‫is simply active
‫and set it to false.
‫All right.
‫Now sending back the response is also pretty easy.
‫We use the 204 code
‫for deleted which will then make it so that actually
‫in Postman we do not even see this response, okay.
‫But we still send it along with the request
‫'cause that's always the best practice.
‫So, it's still a success
‫and then remember we don't send any data.
‫So, simply set it to no.
‫All right, and now of course add it
‫also to all routes here.
‫So that's pretty similar.
‫So deleteMe
‫then here deleteMe as well
‫and now actually we are using the delete http method.
‫Okay, and again, we will not actually delete
‫a user from the database.
‫But as long as the user is no longer accessible anywhere
‫then it's still okay to use this http method here.
‫All right, so let's try this out now.
‫Okay, even though we're not 100% ready yet
‫but let's still try this now.
‫All right,
‫so,
‫deleteMe
‫and it is a protected route
‫and so we need to be signed in
‫and so let's create our authorization header,
‫Bearer Token and of course this one
‫and that's actually it.
‫We don't need to pass any data in the body.
‫We don't need to pass any data in the URL.
‫All right, because again, the only data that is needed
‫is the current user ID and that one isn't coded
‫inside of our adjacent web token.
‫Okay?
‫So what we also need to do is delete
‫and yeah this should work now.
‫So before we do that let's actually get the list
‫of all the users.
‫All right and so the one that we are deleting now
‫is this last one.
‫So this one that we just created in the last lecture.
‫Okay, and we are working with this one
‫because it's the last one who logged in
‫and so it's this token here
‫which is right now stored in our token variable.
‫Okay, and so when we're now deleting the user
‫it will be based on the ID coming from this token.
‫So let's try that now.
‫And indeed we get our 204.
‫And now what I'm interested in is to see
‫if the select property here has changed.
‫And it actually looks exactly the same here.
‫And that's because we're not leaking
‫the select field to the user.
‫And so we actually need to see it here.
‫Okay and so indeed we have active here set to false.
‫Okay, so that's what I wanted to say before.
‫So we're not leaking the active fields
‫to the user, not the select field.
‫So active is only visible for us here
‫in compass but not for the user.
‫Now as a last step,
‫we then of course do not want to show up the
‫inactive users in this output, right.
‫And how do you think we could implement this?
‫Well we're gonna use something that is way back
‫that we talked about like two or three sections ago
‫which is query middleware, okay.
‫So query middleware is perfect for this
‫because now we can basically add a step
‫before any other query that we're doing then
‫somewhere in our application.
‫So let's go to our user model here
‫and add that middleware here.
‫So userSchema
‫.pre, so something that will happen
‫before a query and that query will be a find.
‫Okay, so this is what makes this query middleware.
‫Then a regular function
‫because remember that otherwise
‫we're not having access to the discord
‫or at least it won't have the value
‫that we expect it to have.
‫And remember that here we actually
‫used a regular expression before
‫basically to say that we want this middleware function
‫to apply to every query that starts with find.
‫So not just find but also stuff like find and update,
‫find and delete, and all queries like that.
‫Okay, and so we use a regular expression
‫looking for words or strings that start with find.
‫So that's what this symbol here does.
‫And then end the regular expression.
‫So a very simple one.
‫This is the one that even I can write
‫without going to Google first
‫and try to find it there.
‫Okay, so remember this is query middleware
‫and so therefore this points to the current
‫query.
‫Okay, and so let's just quickly go back here
‫to see how it works.
‫So we have our get all users here
‫and here of course we have a find query.
‫And now before that query is actually executed
‫we want to add something to it.
‫Which is that we only want to find documents
‫which have the active property set to true.
‫All right, so that's easy.
‫Here it is.
‫And so
‫this
‫.find
‫and then of course our filter object
‫only documents with active set to true.
‫And that's it.
‫Calling the next middleware and we're done.
‫Okay, and so if we now do the same query
‫then this last one should no longer show up
‫because again it has active set to false.
‫And so it's not going to match the query
‫that we just wrote.
‫Okay, now we don't get any users here
‫and I guess that's because the other ones
‫they do not have explicitly
‫the active property set to true.
‫And so let's do what we actually did in that other section
‫where we say that active should not be false.
‫Okay,
‫so we use the not equal to
‫operator and that of course should be in it's own object.
‫So not equal to false.
‫Okay, so that is quite different here in this case.
‫All right, so all documents where active
‫is not equal to false should now show up
‫and so the other two should now be back.
‫And indeed here they are.
‫Okay and so this is how we basically delete our users
‫while effectively not deleting them from the database.
‫Okay, so we're not deleting documents
‫we're only marking them as inactive.
‫Okay, let's just quickly save this here.
‫Delete
‫current user.
‫Great and with this we actually finished
‫the authentication and authorization part
‫of this section.
‫So everything that was related to these topics
‫and also to to users like updating and deleting users.
‫That's also kind of a part of authentication
‫and authorization.
‫Now in the rest of this section,
‫we're gonna talk about security
‫because of course that's also kind of related
‫to authentication.
‫Okay, so we're gonna talk about a couple of
‫best practices and then also implement
‫some of them into our project.