All language subtitles for 017 Deleting the Current User_Downloadly.ir_en

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.