Time for the third assignment in this course.

In this module, we have been exploring user authentication a lot of detail.

Now in this assignment we will work further on user authentication.

We will add yet the category of accounts called as an admin.

Ad admin account is a super account that has

a lot of privileges of performing various operations.

An ordinary user account can only perform certain operations on over server.

Similarly, an unregistered request coming in from a client that is not logged in,

can only perform certain operations on over server.

Now we are going to modify our server

such that Get operations can be performed by anyone.

But you don't need to log into the system to perform Get operations on

the various recipients end points except submission of [inaudible] .

For the remaining operations on the recipient endpoints,

their post put and date operations.

These would be restricted to be performed only by admin users.

An ordinary user cannot perform these operations.

Obviously you don't want an ordinary user to be submitting

new Dishes or promotions or leader information,

or modifying existing information or even deleting this existing information.

This should be the privilege of only the system administrator for our server.

Also, we will ensure that an ordinary user can post comments about specific Dishes.

That is acceptable.

Similarly an ordinary user can upgrade and delete comments that he or she has posted.

Other users or even the admin cannot update or delete comments posted by another user.

So this is another restriction that we're going to place in our server.

Now let's go ahead and examine how are going to be going about implementing this.

And how exactly our server does these operations.

First and foremost, I will illustrate to you how you would

create in an admin account in your system.

You realize that we have to go behind the scenes to create an admin account,

simply because we don't want an admin account to be created by

performing the signed up operation on our users slash sign up account.

This will leave our server vulnerable to attacks.

So, an admin account can only be set up

behind the scenes by directly accessing their database.

So let's look at how we go about doing this in

the illustration that I'm going to show you right after.

Now to examine our database,

let me start the Mongo rapport and the command prompt,

and then go to the conFusion folder and then let me

examine the users that are registered in my database at this moment.

So you can see that I have just one user registered.

So let me set up two additional accounts.

One for an ordinary user,

and one which is going to be an admin.

So we will sign up.

The admin and the second user also from our sign up point,

thereafter they will come back to the mongo rapport and then set up the admin account,

explicitly by modifying that record in our database.

Going to post them,

let me sign up

two additional users so we had earlier signed up one user of the last name,

so I'm going to sign up another user into my system.

And so a second user is now registered successfully.

Now let me also register an admin account,

so for the admin account I will set up the username as admin,

and then sign up an admin user.

So, we see that we have now added two new accounts to our system.

Going to the mongul rapport,

let me again repeat the db.users.find

and let me do it so that it looks more easier to read.

And so when I do this you can see that we have an admin account here,

with the username as an admin,

ignore the first name and last name I'll set up

the first name and last name to be same for all the three.

Then, we have the other user account that I have set up with the username here,

and the third user account that we already had in our database.

So now we have three user accounts,

two user accounts here and an admin account.

Now of course you'll see that in

the user account we have this flag called the admin flag which is set to

false for any account that is signed up on the user

slash sign up in point.

What is the default way that you should set up account?

You cannot allow a user to configure an admin account

by doing anything directly on the rest AP in point.

Instead, we will go behind the scenes and in the Mongo rapport I'm going to

modify this record for the admin user,

by saying db.users.update,

and then will supply the username as admin here.

So we're going to be updating this record,

and then we'll see dollar set.

Recall how we were manipulating the Mongo D-B.

So we'll say, dollars set admin true.

So what we are doing here is that we are searching

for this user account with the user username admin,

and then we are setting up there admin flag to choose here.

By using that dollar set up.

So this is how we would update an account to be an admin account.

And so you see that this has modified the results.

So let's again check the account.

So, now when you check the account you'll see that for the admin account,

the admin flag is now set to true.

So that is how you will end up creating an admin account.

Now, the admin account as we would expect has additional privileges.

So, once you complete this assignment,

then you will notice that get operation can be performed by any user,

on the slash Dishes,

slash Dishes, slash a specific Dish and point,

slash promotions, and slash promotions,

slash specific promotion in point.

And similarly for the leaders in point also.

What that post put and delete operations on

these end points can only be performed by and then users.

Now in addition, their comments end point,

they will allow only a registered user who has logged in to

access comments for specific [inaudible] ,

we will allow a logged in user to post comments.

We have already set this up in the exercise.

So when the user posts the comment we have

ensured that we verify the authenticity of the user,

and then when the comments posted we have set up

the author ID for the comment using the user ID.

So we have already completed that.

But now, in addition for the put and the delete operations on comments,

only the user that has submitted that specific comment will be

allowed to do put and delete operations on his or her own comments.

Any other user cannot modify somebody else's comments.

Similarly even the admin cannot modify somebody else's comments,

or delete somebody else's comments.

So, that's the second part of this assignment that you're going to be doing.

And the third part is that,

an admin can query the slash users endpoint,

and ask for the list of registered users.

No other ordinary user can do this query.

So, this is the other restriction that we are going to put in there.

Now, in order to verify that a user is an admin,

we will first verify that the user is a registered user.

So, the verify user function that we have already implemented in

the authenticate.js should be applied even where you need to check for the admin.

First you check that is a verified user.

Thereafter, you will introduce another function

called verify admin in the authenticate.js file,

which will check to ensure that the user is an admin.

Now to check whether a user is an admin,

all that you need to do is to check direct.user,

that is on the request object direct.user there,

check to see whether the admin flag is true or not.

If the admin flag is true,

you will allow the normal process

of proceeding farther to the middle where it will happen.

If the user is not an admin,

you will generate an error,

and send back an error message back to the client side.

So, that's how we're going to be handling the admin users account.

Now, when a user is trying to modify,

or delete his or her own comments,

we have to check to make sure that the author of the comment is the

same as the user that is trying to modify the comment.

Now, direct.user also has the ID field.

So, you need to cross check that with the author field of the comment.

If these two match,

then you will allow the user to perform the put or delete operations.

If they don't match,

then you will not permit the put or the delete operations on that specific comment.

So, this is the other aspect that you're going to be

implementing as part of your assignment.

Let's look at how all these things work,

by using postman to perform various operations on our server.

Going back to postman, let me first perform a get operation on

dishes to just check to see what is in my database.

So, if I perform a get operation on the dishes,

notice that I am not putting any authentication in the header.

Get operation is allowed by anybody.

So, when I perform the get operation,

I can see that I already have one dish with a comment already in place in the dish.

This comment was posted by this user already.

So, we already have one dish in the system there.

So, this is perfectly fine.

I'm going to delete the dish.

Now to delete the dish,

obviously that operation cannot be performed by an ordinary user.

So, you can see that I am logging in as a regular user.

So, let me log in as a regular user.

So when I login, I will get the token.

So, I'm going to copy this token and save it.

Now that I have my token,

let me perform a delete operation on the dishes.

So, when I go to the delete operation,

so let me select this get and then do a delete operation on the dishes.

And in the header,

let me include the authorization here.

And you would notice that,

when we paste in the request and then send the delete authorization,

you would notice that it immediately comes back with this message here,

as you can see in the preview.

It says you are not authorized to perform this operation.

And then the error code is 403 forbidden.

So, this is the message that is generated by

the verify admin function that we going to be implementing as part of this exercise.

So, if the user is not an admin,

then this is the message that your verify admin will generate.

And it will not allow the request to go beyond that point.

So, you can see that I have closed off the delete operation.

Now, how do you do this?

In your code, you have seen that in order to apply the verify user,

we said authenticate.verify user in the post,

put and delete operations.

Now, you can change the middleware one after another.

So, we can say, authenticate.verifyuser comma, and then following that,

you can say authenticate.verifyadmin to

apply the verify admin right after the verify user.

So, if you want a operation to be restricted only to the admin,

you first do the verify user part,

and then immediately following that,

you apply the verify admin middleware right after that.

So if these two checks successfully pass through,

then you will go on to perform the operation.

If the verify admin check fails,

you will return this error message as you see here,

and then abort the operation that part.

So, you will return a next error from your verify admin if the user is not an admin.

So, I have demonstrated to you how you're going to

be using the admin users account to restrict operations for the put,

post, and delete operations.

Same thing, post and put operations will also not be permitted on any of these imports.

Now, but let me demonstrate the other aspect here.

So, you saw that in there when we performed the get operation,

you saw that there was already a comment that was posted by

the username Jogesh the first user that is in my system.

Now, I'm going to log in as the other user.

So, I will log in as into my second account which is muppala,

and then when I log in, I again get the token.

So, let me take this token here,

let me copy this token.

Now what I'm going to do is,

I will do a get on the local host dishes.

So, let me do a get on the local host dishes to show

you the specific comment inside here.

So, this particular comment with this item.

So what I'm going to do is,

I'm going to copy the dish ID.

I'm also going to copy that comment ID from here,

and I'm going to perform

a delete operation on this specific Dish.

And recall that we have

that /comments/ and then this particular comment ID.

Now, remember that this comment was posted by this username but I have

now log in myself as the other user with a different username.

So, when I now perform the delayed operation using their other account,

you would immediately notice that in here it says you are

not authorized to delete this comment and then it says 4,0,3.

Same thing, if you try to do

a put operation on that specific comment logged in as another user,

it will say you are not authorized to update this comment.

So both put, delete and update of somebody else's comment is not permitted.

So now, let me log in as the admin at this point and then let me try to delete

that particular comment and you would see that the same message will be generated.

So and I been also cannot delete or update somebody else's comments.

So to log in as an admin,

let me go into the post here and then let me log in as an admin.

Now remember that these tokens will be valid for 3,600 seconds so you can save

these three tokens that you generate for the three user so

you don't need to keep logging in as that particular user.

As long as you use the right token in the header,

your operations will perform just fine identifying the three different uses.

So let me log in as the admin here.

So when I log in as the admin I get the token

here so I'm going to copy and save this token.

Just remember which token belongs to who,

when you make a copy of this.

Now, going back to the delete current operation.

I'm going to go into the header and then I'm going to change this to

the token for the admin and then try to perform the same delete operation.

And then you see that even the admin is

not authorized to delete the comment posted by another user.

This is perfectly acceptable.

But let's try to delete the same comment by this user

that created that comment and you would see that can be successfully done.

So let's perform that operation.

So to do that, I'm going to go back and fetch the token that I have

got for the first user and then change the authorization field.

So now, for this delete operation,

I'm going to change this to bearer.

And then this is the token for the first user, the username Jogesh.

So, when I try to delete that comment,

you will notice that that comment is now deleted successfully.

So as you can see from the stamps,

the comment can be only deleted by the user that created that comment.

Now the next step,

when we do the delete operation on the dishes.

We saw earlier that if we did the delete operation as an ordinary user,

you get the message saying you're not authorized to perform this operation.

So I'm going to change this token to the token of the admin and then

show you that an admin can perform the delete operation on the dishes in part.

So going into this request,

let me change their token to be the token for the admin users.

And so when I perform the delete operation as the admin user,

you would notice that the delete operation is

successful and then replies back with the message here.

So now when I do,

I get on the dishes endpoint,

you will notice that the get operations shows that my dishes have been emptied.

Now, the other operations that you will also implement in

this assignment is that we can do a get operation on the slash users endpoint.

So when you do a get operation of the slash users endpoint,

you would notice that if you are not an authorized user,

it will say you are not authorized to perform this operation.

So the localhost:3000/users/endpoint.

They are now going to be allowing this to be performed only by the admin.

So if an ordinary user,

if you log in as an ordinary user with the header you will

not be allowed to perform this operation.

Now, let me change this token to the token

of the admin and then you will see

that the admin will be allowed to perform this operation.

So going to the get.

Let me change this token to the token

for the admin user and then when I perform the get operation on that,

it returns as you can see,

there're three users that are registered in my system.

It shows that user number one,

user number two and user number three.

And of course notice that the hash and salt are removed when

the message is returned by the Server-side to the Client-side.

So the hash and salt information will have been never revealed outside.

So Mongos will automatically take care of filtering out

that information before it sends back the users information.

Because you should not be revealing the hash and salt information to the outside world.

So this is the three user account information that is returned.

So this is return only if you perform the get operation on

the slash users endpoint as the Admin user.

If you perform the same request as any other user,

this will not be permitted.

So again, you will check first verify user and then check the verified admin.

And only if it has an admin then this operation can be performed on this endpoint.

So these are all the various tasks that you will do as part of this assignment.

The details of how these need to be done are documented in the assignment instructions.

So read through the instructions before you proceed to complete the third assignment.

Have fun completing the third assignment.

Assignment 3 Requirements (Video): User Authentication

Server-side Development with NodeJS, Express and MongoDB

Meet the Instructors