1
00:00:03,920 --> 00:00:07,970
Time for the third assignment in this course.

2
00:00:07,970 --> 00:00:13,110
In this module, we have been exploring user authentication in a lot of detail.

3
00:00:13,110 --> 00:00:14,705
Now, in this assignment,

4
00:00:14,705 --> 00:00:17,905
we will work further on user authentication.

5
00:00:17,905 --> 00:00:22,965
We will add yet another category of accounts called as an Admin.

6
00:00:22,965 --> 00:00:26,880
An Admin account is a super account that has

7
00:00:26,880 --> 00:00:31,460
a lot of privileges of performing various operations.

8
00:00:31,460 --> 00:00:37,410
An ordinary user account can only perform certain operations on our server.

9
00:00:37,410 --> 00:00:43,445
Similarly, an unregistered request coming in from a client

10
00:00:43,445 --> 00:00:49,610
that is not logged in can only perform certain operations on our server.

11
00:00:49,610 --> 00:00:52,400
Now, we're going to modify our server such

12
00:00:52,400 --> 00:00:55,865
that get operations can be performed by anyone.

13
00:00:55,865 --> 00:01:00,350
You don't need to log into the system to perform get operations on

14
00:01:00,350 --> 00:01:06,110
the various rest API endpoints except submission of comments.

15
00:01:06,110 --> 00:01:11,625
For the remaining operations on the rest API endpoints,

16
00:01:11,625 --> 00:01:15,365
the POST put and delete operations,

17
00:01:15,365 --> 00:01:20,190
these will be restricted to be performed only by admin users,

18
00:01:20,190 --> 00:01:23,780
an ordinary user cannot perform these operations.

19
00:01:23,780 --> 00:01:30,215
Obviously, you don't want an ordinary user to be submitting new dishes, or promotions,

20
00:01:30,215 --> 00:01:34,975
or leader information, or modifying existing information,

21
00:01:34,975 --> 00:01:37,780
or even deleting these existing information.

22
00:01:37,780 --> 00:01:45,290
This should be the privilege of only the system administrator for our server.

23
00:01:45,290 --> 00:01:50,870
Also, we will ensure that an ordinary user can

24
00:01:50,870 --> 00:01:56,010
post comments about specific dishes, that is acceptable.

25
00:01:56,010 --> 00:02:03,015
Similarly, an ordinary user can update and delete comments that he or she has posted.

26
00:02:03,015 --> 00:02:10,230
Other users or even the admin cannot update or delete comments posted by another user.

27
00:02:10,230 --> 00:02:14,565
So, this is another restriction that we're going to place in our server.

28
00:02:14,565 --> 00:02:18,335
Now, let's go ahead and examine how we're going to be going about

29
00:02:18,335 --> 00:02:23,299
implementing this and how exactly our server does these operations.

30
00:02:23,299 --> 00:02:26,720
First and foremost, I will illustrate to you how you

31
00:02:26,720 --> 00:02:31,240
would create an admin account in your system.

32
00:02:31,240 --> 00:02:33,770
You will realize that we have to go behind

33
00:02:33,770 --> 00:02:37,325
the scenes to create an admin account simply because,

34
00:02:37,325 --> 00:02:41,930
we don't want an admin account to be created by performing

35
00:02:41,930 --> 00:02:47,030
the sign-up operation on our users/signup account.

36
00:02:47,030 --> 00:02:50,670
This will leave our server vulnerable to attacks.

37
00:02:50,670 --> 00:02:54,185
So, an admin account can only be set up

38
00:02:54,185 --> 00:02:59,085
behind the scenes by directly accessing the database.

39
00:02:59,085 --> 00:03:02,090
So, let's look at how we go about doing

40
00:03:02,090 --> 00:03:08,340
this in the illustration that I am going to show you right after.

41
00:03:08,380 --> 00:03:11,700
Now, to examine our database,

42
00:03:11,700 --> 00:03:15,865
let me start the Mongo Ripple at the Command prompt,

43
00:03:15,865 --> 00:03:21,740
and then go to the confusion folder and then let me

44
00:03:21,740 --> 00:03:27,830
examine the users that are registered in my database at this moment.

45
00:03:27,830 --> 00:03:32,015
So, you can see that I have just one user registered.

46
00:03:32,015 --> 00:03:35,735
So, let me set up two additional accounts,

47
00:03:35,735 --> 00:03:37,695
one for an ordinary user,

48
00:03:37,695 --> 00:03:40,280
and one which is going to be an admin.

49
00:03:40,280 --> 00:03:47,415
So, we will sign up the admin and the second user also from our sign-up point,

50
00:03:47,415 --> 00:03:51,935
thereafter they will come back to the Mongo Ripple and then set up the admin account

51
00:03:51,935 --> 00:03:57,110
explicitly by modifying the record in our database.

52
00:03:57,110 --> 00:03:58,935
Going to Postman pin,

53
00:03:58,935 --> 00:04:03,780
let me sign up two additional users.

54
00:04:03,780 --> 00:04:07,755
So, we had earlier signed up one user with this name,

55
00:04:07,755 --> 00:04:15,660
so I'm going to sign up another user into my system,

56
00:04:15,660 --> 00:04:20,945
and so, a second user is now registered successfully.

57
00:04:20,945 --> 00:04:24,660
Now, let me also register an admin account.

58
00:04:24,660 --> 00:04:25,880
So, for the admin account,

59
00:04:25,880 --> 00:04:31,910
I will set up the username as admin and then sign up an admin user.

60
00:04:31,910 --> 00:04:38,545
So, we see that we have now added two new accounts to our system.

61
00:04:38,545 --> 00:04:40,455
Going to the Mongo Ripple,

62
00:04:40,455 --> 00:04:43,870
let me again repeat the

63
00:04:43,870 --> 00:04:51,110
db.user.find() and let me do it pretty so that it looks more easier to read.

64
00:04:51,110 --> 00:04:52,845
So, when I do this,

65
00:04:52,845 --> 00:04:58,655
you can see that we have an admin account here with the user name as an admin.

66
00:04:58,655 --> 00:05:00,770
Ignore the first name and last name,

67
00:05:00,770 --> 00:05:05,190
I'll set up this first name and last name to be the same for all the three.

68
00:05:05,190 --> 00:05:12,800
Then, we have the other user account that I have set up with the username here,

69
00:05:12,800 --> 00:05:17,190
and the third user account that we already had in our database.

70
00:05:17,190 --> 00:05:19,750
So, now we have three user accounts;

71
00:05:19,750 --> 00:05:22,215
two user accounts here,

72
00:05:22,215 --> 00:05:23,860
and an admin account.

73
00:05:23,860 --> 00:05:28,395
Now, of course, you'll see that in the user accounts,

74
00:05:28,395 --> 00:05:32,690
we have this flag called as the admin flag which is set to false for

75
00:05:32,690 --> 00:05:38,100
any account that is signed up on this /users/signup endpoint.

76
00:05:38,100 --> 00:05:40,740
That is the default way that you should set up accounts.

77
00:05:40,740 --> 00:05:44,465
You cannot allow a user to configure an admin account

78
00:05:44,465 --> 00:05:48,945
by doing anything directly on the rest API endpoint.

79
00:05:48,945 --> 00:05:53,600
Instead, we will go behind the scenes and then in the Mongo Ripple,

80
00:05:53,600 --> 00:06:00,510
I'm going to modify this record for the admin user by

81
00:06:00,510 --> 00:06:07,920
saying db.users.update and then

82
00:06:07,920 --> 00:06:15,205
we'll supply the username as admin here.

83
00:06:15,205 --> 00:06:25,470
So, we're going to be updating verse record and then we'll say {$set:

84
00:06:25,470 --> 00:06:31,520
recall how we were manipulating the MongoDB so we'll

85
00:06:31,520 --> 00:06:39,180
say {$set: {"admin": "true" }}.

86
00:06:39,180 --> 00:06:42,980
So, what we are doing here is that we are searching

87
00:06:42,980 --> 00:06:47,810
for this user account with the username admin,

88
00:06:47,810 --> 00:06:52,190
and then we are setting up the admin flag to true

89
00:06:52,190 --> 00:06:58,125
here by using the $set option.

90
00:06:58,125 --> 00:07:02,520
So, this is how we would update an account to be an admin account.

91
00:07:02,520 --> 00:07:08,010
So, you see that this has modified the results.

92
00:07:08,010 --> 00:07:11,880
So, let's again check the accounts.

93
00:07:11,880 --> 00:07:13,410
Now, when you check the account,

94
00:07:13,410 --> 00:07:16,140
you'll see that for the admin account,

95
00:07:16,140 --> 00:07:19,475
the admin flag is now set to true,

96
00:07:19,475 --> 00:07:22,810
so that is how you will end up creating an admin account.

97
00:07:22,810 --> 00:07:27,920
Now, the Admin account as we would expect has additional privileges.

98
00:07:27,920 --> 00:07:33,400
So, once you complete this assignment then,

99
00:07:33,400 --> 00:07:38,525
you would notice that the get operation can be performed by any user on

100
00:07:38,525 --> 00:07:45,080
the /dishes/dishes/aspecificdishendpoint/promotions

101
00:07:45,080 --> 00:07:50,570
and the /promotions/specificpromotionendpoint and similarly,

102
00:07:50,570 --> 00:07:52,985
for the leaders in points also.

103
00:07:52,985 --> 00:07:55,590
But the POST, put,

104
00:07:55,590 --> 00:08:02,195
and delete operations on these endpoints can only be performed by admin users.

105
00:08:02,195 --> 00:08:08,110
Now, in addition, the comments endpoint,

106
00:08:08,110 --> 00:08:14,110
we would allow only a registered user who has logged in to

107
00:08:14,110 --> 00:08:20,835
access comments for a specific dish,

108
00:08:20,835 --> 00:08:25,990
we will allow a logged in user to post comments.

109
00:08:25,990 --> 00:08:28,730
We have already set this up in the exercise so,

110
00:08:28,730 --> 00:08:31,290
when the user posts the comment,

111
00:08:31,290 --> 00:08:34,150
we have ensured that we verify

112
00:08:34,150 --> 00:08:37,150
the authenticity of the user and then when the comment is posted,

113
00:08:37,150 --> 00:08:44,060
we have setup the author ID for the comment using the user ID.

114
00:08:44,060 --> 00:08:46,140
So, we have already completed that.

115
00:08:46,140 --> 00:08:48,625
But now, in addition,

116
00:08:48,625 --> 00:08:55,220
for the put and the delete operations on comments,

117
00:08:55,220 --> 00:08:59,480
only the user that has submitted the specific comment will be

118
00:08:59,480 --> 00:09:04,180
allowed to do put and delete operations on his or her own comments.

119
00:09:04,180 --> 00:09:08,480
Any other user cannot modify somebody else's comments.

120
00:09:08,480 --> 00:09:13,355
Similarly, even the admin cannot modify somebody else's comments,

121
00:09:13,355 --> 00:09:14,960
or delete somebody else's comment.

122
00:09:14,960 --> 00:09:18,850
So, that's the second part of this assignment that you're going to be doing.

123
00:09:18,850 --> 00:09:22,910
The third part is that an admin can query

124
00:09:22,910 --> 00:09:31,115
the /users end point and ask for the list of registered users,

125
00:09:31,115 --> 00:09:35,090
no other ordinary user can do this query.

126
00:09:35,090 --> 00:09:38,550
So, this is the other restriction that we're going to put in there.

127
00:09:38,550 --> 00:09:42,745
Now, in order to verify that a user is an admin,

128
00:09:42,745 --> 00:09:46,770
we will first verify that the user is a registered user.

129
00:09:46,770 --> 00:09:51,470
So, the verify user function that we have already implemented in the

130
00:09:51,470 --> 00:09:56,450
authenticate.js should be applied even where you need to check for the admin.

131
00:09:56,450 --> 00:09:59,855
First, you check that is a verified user, thereafter,

132
00:09:59,855 --> 00:10:05,795
you will introduce another function called verifyAdmin in the authenticate.js

133
00:10:05,795 --> 00:10:12,285
file which will check to ensure that the user is an admin.

134
00:10:12,285 --> 00:10:15,190
Now, to check whether a user is an admin,

135
00:10:15,190 --> 00:10:19,900
all that you need to do is to check the rec.user that is on

136
00:10:19,900 --> 00:10:24,855
the request object rec.user there,

137
00:10:24,855 --> 00:10:28,325
check to see whether the admin flag is true or not.

138
00:10:28,325 --> 00:10:30,375
If the admin flag is true,

139
00:10:30,375 --> 00:10:39,315
you will allow the normal process of proceeding further to the [inaudible] happen.

140
00:10:39,315 --> 00:10:41,570
If the user is not an admin,

141
00:10:41,570 --> 00:10:49,075
you will generate an error and send back an error message back to the client side.

142
00:10:49,075 --> 00:10:53,945
So, that's how we're going to be handling the admin users account.

143
00:10:53,945 --> 00:11:03,165
Now, when a user is trying to modify or delete his or her own comments,

144
00:11:03,165 --> 00:11:06,320
we have to check to make sure that the author of the comment is the

145
00:11:06,320 --> 00:11:10,245
same as the user that is trying to modify the comment.

146
00:11:10,245 --> 00:11:13,085
Now, the rec.user also has the ID field,

147
00:11:13,085 --> 00:11:16,860
so you need to cross check that with the author field of the comment.

148
00:11:16,860 --> 00:11:18,255
If these two match,

149
00:11:18,255 --> 00:11:22,390
then you will allow the user to perform the put or delete operations.

150
00:11:22,390 --> 00:11:24,050
If they don't match,

151
00:11:24,050 --> 00:11:31,190
then you will not permit the put or the delete operations on that specific comment.

152
00:11:31,190 --> 00:11:33,590
So this is the other aspect that you're going to

153
00:11:33,590 --> 00:11:37,185
be implementing as part of your third assignment.

154
00:11:37,185 --> 00:11:40,420
Let's look at how all these things work by

155
00:11:40,420 --> 00:11:44,500
using Postman to perform various operation on our server.

156
00:11:44,500 --> 00:11:46,545
Going back to Postman,

157
00:11:46,545 --> 00:11:49,725
let me first perform a GET operation on

158
00:11:49,725 --> 00:11:53,920
dishes to just check to see what is in my database.

159
00:11:53,920 --> 00:11:56,140
So, if I perform a GET operation on the dishes,

160
00:11:56,140 --> 00:12:00,270
notice that I am not putting any authentication in the header.

161
00:12:00,270 --> 00:12:02,500
GET operation is allowed by anybody.

162
00:12:02,500 --> 00:12:04,420
So, when I perform the GET operation,

163
00:12:04,420 --> 00:12:13,985
I can see that I already have one dish with a comment already in place in that dish.

164
00:12:13,985 --> 00:12:18,900
This comment was posted by this user already.

165
00:12:18,900 --> 00:12:23,895
So, we already have one dish in the system there.

166
00:12:23,895 --> 00:12:26,520
So, this is perfectly fine,

167
00:12:26,520 --> 00:12:28,405
I am going to delete the dish.

168
00:12:28,405 --> 00:12:29,875
Now, to delete the dish,

169
00:12:29,875 --> 00:12:33,855
obviously that operation cannot be performed by an ordinary user.

170
00:12:33,855 --> 00:12:36,500
So, let me login as,

171
00:12:36,500 --> 00:12:40,310
so you can see that I am logging in as a regular user.

172
00:12:40,310 --> 00:12:44,940
So, let me login as a regular user.

173
00:12:44,940 --> 00:12:47,140
So, when I login, I will get the token.

174
00:12:47,140 --> 00:12:49,725
So, I'm going to copy this token and save it.

175
00:12:49,725 --> 00:12:53,845
Now, that I have my token,

176
00:12:53,845 --> 00:12:58,770
let me perform a DELETE operation on the dishes.

177
00:12:58,770 --> 00:13:01,985
So, when I go to the DELETE operation.

178
00:13:01,985 --> 00:13:07,370
So, let me select this GET and then do a DELETE operation with the dishes.

179
00:13:07,370 --> 00:13:13,440
In the header, let me include the authorization here and you would notice

180
00:13:13,440 --> 00:13:22,144
that when we paste in the request and then send the DELETE authorization,

181
00:13:22,144 --> 00:13:27,325
you would notice that it immediately comes back with this message here,

182
00:13:27,325 --> 00:13:28,990
as you can see in the preview,

183
00:13:28,990 --> 00:13:33,510
it says "You are not authorized to perform this operation! "

184
00:13:33,510 --> 00:13:37,410
Then the error code is 403 forbidden.

185
00:13:37,410 --> 00:13:41,540
So, this is a message that has generated by

186
00:13:41,540 --> 00:13:46,470
the verifyAdmin function that you're going to be implementing as part of this exercise.

187
00:13:46,470 --> 00:13:49,720
So, if the user is not an admin,

188
00:13:49,720 --> 00:13:53,085
then this is the message that your verifyAdmin will

189
00:13:53,085 --> 00:13:57,880
generate and it will not allow the request to go beyond that point.

190
00:13:57,880 --> 00:14:04,150
So, you can see that I have closed off the DELETE operation.

191
00:14:04,150 --> 00:14:05,895
Now, how do you do this?

192
00:14:05,895 --> 00:14:11,925
In your code, you have seen that in order to apply the verifyUser,

193
00:14:11,925 --> 00:14:16,270
we set authenticate.verifyUser in the POST,

194
00:14:16,270 --> 00:14:18,270
PUT, and DELETE operations.

195
00:14:18,270 --> 00:14:22,105
Now, you can chain the middleware one after another.

196
00:14:22,105 --> 00:14:25,200
So, we can say authenticate.verifyUser comma

197
00:14:25,200 --> 00:14:28,905
and then following that you can say authenticate.verifyAdmin,

198
00:14:28,905 --> 00:14:32,190
to apply the verifyAdmin right after the verifyUser.

199
00:14:32,190 --> 00:14:35,840
So, if you want a operation to be restricted only to the admin,

200
00:14:35,840 --> 00:14:39,520
you first do the verifyUser part and then immediately following that,

201
00:14:39,520 --> 00:14:42,085
you apply the verifyAdmin middleware.

202
00:14:42,085 --> 00:14:45,274
Right after that. So, if these two checks,

203
00:14:45,274 --> 00:14:49,615
successfully pass through, then you will go onto perform the operation.

204
00:14:49,615 --> 00:14:52,240
If the verifyAdmin check fails,

205
00:14:52,240 --> 00:14:54,870
you will return this error message as you see

206
00:14:54,870 --> 00:14:57,995
here and then abort the operation that part.

207
00:14:57,995 --> 00:15:01,300
So, you will return the next error from your verifyAdmin,

208
00:15:01,300 --> 00:15:03,260
if the user is not an admin.

209
00:15:03,260 --> 00:15:08,100
So, I have demonstrated to you how you're going to

210
00:15:08,100 --> 00:15:12,865
be using the admin users account to restrict operations for a PUT,

211
00:15:12,865 --> 00:15:15,285
POST, and DELETE operations.

212
00:15:15,285 --> 00:15:21,935
Same thing, POST and PUT operations will also not be permitted on any of these n parts.

213
00:15:21,935 --> 00:15:26,360
Now, then let me demonstrate the other aspect here.

214
00:15:26,360 --> 00:15:28,710
So, you saw that in there,

215
00:15:28,710 --> 00:15:30,450
when we perform the GET operation,

216
00:15:30,450 --> 00:15:37,570
you saw that there was already a comment that was posted by the username Jogesh,

217
00:15:37,570 --> 00:15:40,230
the first user that is in my system.

218
00:15:40,230 --> 00:15:43,385
Now, I'm going to login as the other user.

219
00:15:43,385 --> 00:15:53,080
So, I will login as into my second account which is Muppala and then when I login,

220
00:15:53,080 --> 00:15:54,175
I again get the token.

221
00:15:54,175 --> 00:15:56,585
So, let me take this token here.

222
00:15:56,585 --> 00:15:58,645
Let me copy this token.

223
00:15:58,645 --> 00:16:04,685
Now, what I'm going to do is I will do a GET on the localhost dishes.

224
00:16:04,685 --> 00:16:12,520
So, let me do a GET on the localhost dishes to show you the specific comment inside here.

225
00:16:12,520 --> 00:16:16,030
So, this particular comment with this ID.

226
00:16:16,030 --> 00:16:17,640
So, what I'm going to do is,

227
00:16:17,640 --> 00:16:20,400
I'm going to copy that dish ID.

228
00:16:20,400 --> 00:16:26,810
I'm also going to copy the comment ID from here and I'm going to perform

229
00:16:26,810 --> 00:16:38,700
a DELETE operation on this specific dish

230
00:16:38,700 --> 00:16:42,615
and recall that we have

231
00:16:42,615 --> 00:16:50,980
the slash comments slash and then this particular comment ID.

232
00:16:50,980 --> 00:16:55,350
Now, remember that this comment was posted by this username,

233
00:16:55,350 --> 00:17:01,120
but I have now logged in myself as the other user with a different username.

234
00:17:01,120 --> 00:17:07,075
So, when I now perform the DELETE operation using the other account,

235
00:17:07,075 --> 00:17:11,950
you would immediately notice that in here it says,

236
00:17:11,950 --> 00:17:15,550
"You are not authorized to delete this comment! "

237
00:17:15,550 --> 00:17:18,970
Then it says 403, same thing.

238
00:17:18,970 --> 00:17:24,205
If you try to do a PUT operation on that specific comment logged in as another user,

239
00:17:24,205 --> 00:17:30,010
it'll say, "You are not authorized to update this comment!"

240
00:17:30,010 --> 00:17:35,340
So, both PUT, DELETE and UPDATE of somebody else's comment is not permitted.

241
00:17:35,340 --> 00:17:41,855
So now, let me log in as the admin at this point and then let me try to delete

242
00:17:41,855 --> 00:17:50,510
that particular comment and you would see that the same message will be generated.

243
00:17:50,510 --> 00:17:55,890
So, an admin also cannot delete or update somebody else's comments.

244
00:17:55,890 --> 00:17:57,600
So, to login as an admin,

245
00:17:57,600 --> 00:18:02,785
let me go into the POST here and then let me login as an admin.

246
00:18:02,785 --> 00:18:08,585
Now, remember that these tokens will be valid for 33,600 seconds.

247
00:18:08,585 --> 00:18:12,620
So, you can save these three tokens that you generate for the three users.

248
00:18:12,620 --> 00:18:16,270
So, you don't need to keep logging in as that particular user.

249
00:18:16,270 --> 00:18:20,180
As long as you use the right token in the header,

250
00:18:20,180 --> 00:18:25,670
your operations will perform just fine identifying the three different users.

251
00:18:25,670 --> 00:18:28,655
So, let me log in as the admin here.

252
00:18:28,655 --> 00:18:30,670
So, when I log in as the admin,

253
00:18:30,670 --> 00:18:31,680
I get the token here.

254
00:18:31,680 --> 00:18:34,930
So, I'm going to copy and save this token.

255
00:18:35,010 --> 00:18:40,800
Just remember which token belongs to who when you make a copy of this.

256
00:18:40,800 --> 00:18:45,430
Now, going back to this, delete comment operation.

257
00:18:45,430 --> 00:18:54,575
I'm going to go into the header and then I'm going to change this to the token for

258
00:18:54,575 --> 00:19:00,980
the admin and then try to perform the same DELETE operation and then you see

259
00:19:00,980 --> 00:19:08,420
that even the admin is not authorized to delete the comment posted by another user.

260
00:19:08,420 --> 00:19:10,480
This is perfectly acceptable.

261
00:19:10,480 --> 00:19:13,095
But let's try to delete the same comment,

262
00:19:13,095 --> 00:19:15,255
by this user that created

263
00:19:15,255 --> 00:19:18,425
that comment and you would see that that can be successfully done.

264
00:19:18,425 --> 00:19:20,715
So, let's perform that operation.

265
00:19:20,715 --> 00:19:24,720
So to do that, I'm going to go back and fetch the token that I have

266
00:19:24,720 --> 00:19:30,345
got for the first user and then change the Authorization field.

267
00:19:30,345 --> 00:19:33,260
Now, for this DELETE operation,

268
00:19:33,260 --> 00:19:35,860
I'm going to change this to bearer,

269
00:19:35,860 --> 00:19:42,400
and then this is the token for the first user with the username Jogesh.

270
00:19:42,400 --> 00:19:46,100
So, when I try to delete that comment,

271
00:19:46,100 --> 00:19:50,850
you will notice that the comment is now deleted successfully.

272
00:19:50,850 --> 00:19:53,710
So, as you can see from the steps,

273
00:19:53,710 --> 00:19:57,830
the comment can be only deleted by the user that created that comment.

274
00:19:57,830 --> 00:19:59,120
Now, the next step,

275
00:19:59,120 --> 00:20:02,345
when we do the DELETE operation on the dishes,

276
00:20:02,345 --> 00:20:07,120
we saw earlier that if we did the DELETE operation as an ordinary user,

277
00:20:07,120 --> 00:20:09,400
you get a message saying,

278
00:20:09,400 --> 00:20:12,010
"You are not authorized to perform this operation!"

279
00:20:12,010 --> 00:20:16,670
So, I'm going to change this token to the token of the admin and then

280
00:20:16,670 --> 00:20:21,425
show you that an admin can perform the DELETE operation on the dishes and pot.

281
00:20:21,425 --> 00:20:23,480
So, going into this request,

282
00:20:23,480 --> 00:20:30,550
let me change the token to be the token for the admin user.

283
00:20:30,550 --> 00:20:34,765
So, when I perform the DELETE operation as the admin user,

284
00:20:34,765 --> 00:20:37,375
you will notice that the DELETE operation is

285
00:20:37,375 --> 00:20:41,905
successful and then replies back with the message here.

286
00:20:41,905 --> 00:20:45,715
Now, when I do a GET on the dishes endpoint,

287
00:20:45,715 --> 00:20:52,515
you will notice that the GET operations shows that my dishes have been emptied.

288
00:20:52,515 --> 00:20:59,285
Now, the other operation that you will also implement in this assignment,

289
00:20:59,285 --> 00:21:05,670
is that we can do a GET operation on the slash users endpoint.

290
00:21:05,670 --> 00:21:09,285
So, when you do a GET operation on the slash users endpoint,

291
00:21:09,285 --> 00:21:12,690
you will notice that if you are not an authorized user,

292
00:21:12,690 --> 00:21:16,450
it will say you are not authorized to perform this operation.

293
00:21:16,450 --> 00:21:20,850
So, the localhost:3000/users/endpoint, you

294
00:21:20,850 --> 00:21:27,355
are now going to be allowing this to be performed only by the admin.

295
00:21:27,355 --> 00:21:29,265
So, if an ordinary user,

296
00:21:29,265 --> 00:21:32,420
if you log in as an ordinary user with the header,

297
00:21:32,420 --> 00:21:36,510
you will not be allowed to perform this operation.

298
00:21:36,510 --> 00:21:42,390
Now, let me change this token to the token

299
00:21:42,390 --> 00:21:45,345
off the admin and then you will see that

300
00:21:45,345 --> 00:21:48,460
the admin will be allowed to perform this operation.

301
00:21:48,460 --> 00:21:50,135
So, going to the GET,

302
00:21:50,135 --> 00:21:55,600
let me change this token to the token for

303
00:21:55,600 --> 00:22:02,980
the admin user and then when I perform the GET operation on that, it returns.

304
00:22:02,980 --> 00:22:07,945
As you can see, the three users that are registered in my system,

305
00:22:07,945 --> 00:22:11,015
it shows the user number one,

306
00:22:11,015 --> 00:22:13,950
user number two, and user number three.

307
00:22:13,950 --> 00:22:17,530
Of course, notice that the hash and salt are removed,

308
00:22:17,530 --> 00:22:21,965
when the message is returned by the server-side to the client-side.

309
00:22:21,965 --> 00:22:25,490
So, the hash and salt information will be never revealed outside.

310
00:22:25,490 --> 00:22:28,755
So, Mongos will automatically take care of filtering

311
00:22:28,755 --> 00:22:32,580
out that information before it sends back the user's information.

312
00:22:32,580 --> 00:22:35,890
So, because you should not be revealing the hash and

313
00:22:35,890 --> 00:22:39,160
salt information to the outside world.

314
00:22:39,160 --> 00:22:44,510
So, this is the three user accounts information that is returned.

315
00:22:44,510 --> 00:22:47,835
So, this is returned only if you perform the GET operation on

316
00:22:47,835 --> 00:22:51,900
the slash users endpoint as the admin user.

317
00:22:51,900 --> 00:22:56,295
If you perform the same request as any other user,

318
00:22:56,295 --> 00:22:58,055
this will not be permitted.

319
00:22:58,055 --> 00:23:01,065
So, again you will check first,

320
00:23:01,065 --> 00:23:05,040
verifyUser and then check the verifyAdmin and only if it is an admin,

321
00:23:05,040 --> 00:23:08,940
then this operation can be performed on this end point.

322
00:23:08,940 --> 00:23:15,535
So, these are all the various tasks that you will do as part of this assignment.

323
00:23:15,535 --> 00:23:22,990
The details of how these need to be done are documented in the assignment instructions.

324
00:23:22,990 --> 00:23:27,875
So, read through the instructions before you proceed to complete the third assignment.

325
00:23:27,875 --> 00:23:32,380
Have fun completing the third assignment.