1
00:00:03,920 --> 00:00:07,970
Время для третьего задания в этом курсе.

2
00:00:07,970 --> 00:00:13,110
В этом модуле мы очень подробно изучаем аутентификацию пользователей.

3
00:00:13,110 --> 00:00:14,705
Теперь, в этом назначении,

4
00:00:14,705 --> 00:00:17,905
мы будем работать дальше над аутентификацией пользователей.

5
00:00:17,905 --> 00:00:22,965
Мы добавим еще одну категорию учетных записей под названием Admin.

6
00:00:22,965 --> 00:00:26,880
Учетная запись администратора — это супер учетная запись, которая

7
00:00:26,880 --> 00:00:31,460
имеет множество привилегий для выполнения различных операций.

8
00:00:31,460 --> 00:00:37,410
Обычная учетная запись пользователя может выполнять только определенные операции на нашем сервере.

9
00:00:37,410 --> 00:00:43,445
Аналогичным образом, незарегистрированный запрос, поступающий от клиента

10
00:00:43,445 --> 00:00:49,610
, который не вошел в систему, может выполнять только определенные операции на нашем сервере.

11
00:00:49,610 --> 00:00:52,400
Теперь мы собираемся изменить наш сервер таким образом

12
00:00:52,400 --> 00:00:55,865
, чтобы получить операции могут выполняться кем угодно.

13
00:00:55,865 --> 00:01:00,350
Вам не нужно входить в систему для выполнения операций get

14
00:01:00,350 --> 00:01:06,110
на различных конечных точках API остального, кроме отправки комментариев.

15
00:01:06,110 --> 00:01:11,625
Для остальных операций на остальных конечных точках API,

16
00:01:11,625 --> 00:01:15,365
операций ввода и удаления POST,

17
00:01:15,365 --> 00:01:20,190
они будут выполняться только администраторами,

18
00:01:20,190 --> 00:01:23,780
обычный пользователь не может выполнять эти операции.

19
00:01:23,780 --> 00:01:30,215
Очевидно, что вы не хотите, чтобы обычный пользователь отправлял новые блюда или рекламные акции,

20
00:01:30,215 --> 00:01:34,975
или информацию лидера, или изменял существующую информацию

21
00:01:34,975 --> 00:01:37,780
или даже удалял эту существующую информацию.

22
00:01:37,780 --> 00:01:45,290
Это должно быть привилегией только системного администратора для нашего сервера.

23
00:01:45,290 --> 00:01:50,870
Также мы позаботимся о том, чтобы обычный пользователь мог

24
00:01:50,870 --> 00:01:56,010
оставлять комментарии о конкретных блюдах, что является приемлемым.

25
00:01:56,010 --> 00:02:03,015
Аналогичным образом, обычный пользователь может обновлять и удалять комментарии, которые он опубликовал.

26
00:02:03,015 --> 00:02:10,230
Другие пользователи или даже администратор не могут обновлять или удалять комментарии, размещенные другим пользователем.

27
00:02:10,230 --> 00:02:14,565
Итак, это еще одно ограничение, которое мы собираемся разместить на нашем сервере.

28
00:02:14,565 --> 00:02:18,335
Теперь давайте продолжим и рассмотрим, как мы собираемся

29
00:02:18,335 --> 00:02:23,299
реализовать это и как именно наш сервер выполняет эти операции.

30
00:02:23,299 --> 00:02:26,720
Прежде всего, я проиллюстрирую вам, как вы

31
00:02:26,720 --> 00:02:31,240
могли бы создать учетную запись администратора в вашей системе.

32
00:02:31,240 --> 00:02:33,770
Вы поймете, что мы должны пойти за

33
00:02:33,770 --> 00:02:37,325
кулисами, чтобы создать учетную запись администратора просто потому, что

34
00:02:37,325 --> 00:02:41,930
мы не хотим, чтобы учетная запись администратора была создана путем выполнения

35
00:02:41,930 --> 00:02:47,030
операции регистрации на наших пользователей/учетной записи регистрации.

36
00:02:47,030 --> 00:02:50,670
Это сделает наш сервер уязвимым для атак.

37
00:02:50,670 --> 00:02:54,185
Таким образом, учетная запись администратора может быть создана

38
00:02:54,185 --> 00:02:59,085
за кулисами только путем прямого доступа к базе данных.

39
00:02:59,085 --> 00:03:02,090
Итак, давайте посмотрим, как мы делаем

40
00:03:02,090 --> 00:03:08,340
это на иллюстрации, которую я покажу вам сразу после.

41
00:03:08,380 --> 00:03:11,700
Теперь, чтобы проверить нашу базу данных,

42
00:03:11,700 --> 00:03:15,865
позвольте мне запустить Mongo Ripple в командной строке,

43
00:03:15,865 --> 00:03:21,740
а затем перейти в папку путаницы, а затем позвольте мне

44
00:03:21,740 --> 00:03:27,830
проверить пользователей, зарегистрированных в моей базе данных в данный момент.

45
00:03:27,830 --> 00:03:32,015
Итак, вы можете видеть, что у меня зарегистрирован только один пользователь.

46
00:03:32,015 --> 00:03:35,735
Итак, позвольте мне создать две дополнительные учетные записи:

47
00:03:35,735 --> 00:03:37,695
один для обычного пользователя,

48
00:03:37,695 --> 00:03:40,280
а другой, который будет администратором.

49
00:03:40,280 --> 00:03:47,415
Таким образом, мы зарегистрируем администратора и второго пользователя также из нашей точки регистрации,

50
00:03:47,415 --> 00:03:51,935
после чего они вернутся в Mongo Ripple, а затем настроили учетную запись администратора

51
00:03:51,935 --> 00:03:57,110
явно, изменив запись в нашей базе данных.

52
00:03:57,110 --> 00:03:58,935
Перейдя к Postman pin,

53
00:03:58,935 --> 00:04:03,780
позвольте мне зарегистрировать двух дополнительных пользователей.

54
00:04:03,780 --> 00:04:07,755
Итак, мы ранее зарегистрировали одного пользователя с этим именем,

55
00:04:07,755 --> 00:04:15,660
поэтому я собираюсь зарегистрировать другого пользователя в моей системе,

56
00:04:15,660 --> 00:04:20,945
и, таким образом, второй пользователь теперь успешно зарегистрирован.

57
00:04:20,945 --> 00:04:24,660
Теперь позвольте мне также зарегистрировать учетную запись администратора.

58
00:04:24,660 --> 00:04:25,880
Итак, для учетной записи администратора

59
00:04:25,880 --> 00:04:31,910
я настрою имя пользователя как admin, а затем зарегистрирую пользователя администратора.

60
00:04:31,910 --> 00:04:38,545
Итак, мы видим, что мы добавили в нашу систему два новых аккаунта.

61
00:04:38,545 --> 00:04:40,455
Отправляясь в Mongo Ripple,

62
00:04:40,455 --> 00:04:43,870
позвольте мне снова повторить

63
00:04:43,870 --> 00:04:51,110
db.user.find () и позвольте мне сделать это довольно, чтобы его было легче читать.

64
00:04:51,110 --> 00:04:52,845
Итак, когда я это делаю,

65
00:04:52,845 --> 00:04:58,655
вы можете видеть, что у нас есть учетная запись администратора здесь с именем пользователя в качестве администратора.

66
00:04:58,655 --> 00:05:00,770
Игнорируйте имя и

67
00:05:00,770 --> 00:05:05,190
фамилию, я установлю это имя и фамилию, чтобы они были одинаковыми для всех трех.

68
00:05:05,190 --> 00:05:12,800
Затем у нас есть другая учетная запись пользователя, которую я установил с именем пользователя здесь,

69
00:05:12,800 --> 00:05:17,190
и третья учетная запись пользователя, которую мы уже имели в нашей базе данных.

70
00:05:17,190 --> 00:05:19,750
Итак, теперь у нас есть три учетные записи

71
00:05:19,750 --> 00:05:22,215
пользователей; две учетные записи пользователей здесь

72
00:05:22,215 --> 00:05:23,860
и учетная запись администратора.

73
00:05:23,860 --> 00:05:28,395
Теперь, конечно, вы увидите, что в учетных записях пользователей

74
00:05:28,395 --> 00:05:32,690
у нас есть этот флаг, называемый флагом администратора, который установлен в false для

75
00:05:32,690 --> 00:05:38,100
любой учетной записи, которая зарегистрирована на этой конечной точке /users/signup.

76
00:05:38,100 --> 00:05:40,740
Это способ настройки учетных записей по умолчанию.

77
00:05:40,740 --> 00:05:44,465
Вы не можете разрешить пользователю настраивать учетную запись администратора

78
00:05:44,465 --> 00:05:48,945
, выполняя что-либо непосредственно на конечной точке API.

79
00:05:48,945 --> 00:05:53,600
Вместо этого мы пойдем за кулисы, а затем в Mongo Ripple,

80
00:05:53,600 --> 00:06:00,510
я собираюсь изменить эту запись для пользователя администратора,

81
00:06:00,510 --> 00:06:07,920
сказав db.users.update, а затем

82
00:06:07,920 --> 00:06:15,205
мы предоставим имя пользователя как admin здесь.

83
00:06:15,205 --> 00:06:25,470
Итак, мы собираемся обновить запись стиха, а затем мы скажем {$set:

84
00:06:25,470 --> 00:06:31,520
вспомните, как мы манипулировали MongoDB, поэтому мы

85
00:06:31,520 --> 00:06:39,180
скажем {$set: {"admin»: «true»}.

86
00:06:39,180 --> 00:06:42,980
Итак, то, что мы делаем здесь, это то, что мы

87
00:06:42,980 --> 00:06:47,810
ищем эту учетную запись пользователя с именем пользователя admin,

88
00:06:47,810 --> 00:06:52,190
а затем мы устанавливаем флаг admin true

89
00:06:52,190 --> 00:06:58,125
здесь, используя параметр $ set.

90
00:06:58,125 --> 00:07:02,520
Таким образом, мы бы обновили учетную запись, чтобы быть учетной записью администратора.

91
00:07:02,520 --> 00:07:08,010
Итак, вы видите, что это изменило результаты.

92
00:07:08,010 --> 00:07:11,880
Итак, давайте еще раз проверим счета.

93
00:07:11,880 --> 00:07:13,410
Теперь, когда вы проверяете учетную запись,

94
00:07:13,410 --> 00:07:16,140
вы увидите, что для учетной записи

95
00:07:16,140 --> 00:07:19,475
администратора флаг администратора теперь установлен в true,

96
00:07:19,475 --> 00:07:22,810
так что вы в конечном итоге создадите учетную запись администратора.

97
00:07:22,810 --> 00:07:27,920
Теперь учетная запись администратора, как мы ожидали, имеет дополнительные привилегии.

98
00:07:27,920 --> 00:07:33,400
Таким образом, как только вы завершите это задание,

99
00:07:33,400 --> 00:07:45,080
вы заметите, что операция получения может быть выполнена любым пользователем на

100
00:07:45,080 --> 00:07:50,570
/dishes/dishes/specificdishendpoint/promotiones/specificpromotionendpoint и аналогичным образом,

101
00:07:50,570 --> 00:07:52,985
для лидеров в пунктах также.

102
00:07:52,985 --> 00:07:55,590
Но

103
00:07:55,590 --> 00:08:02,195
операции POST, put и delete на этих конечных точках могут выполняться только администраторами.

104
00:08:02,195 --> 00:08:08,110
Теперь, кроме того, комментарии конечной точки,

105
00:08:08,110 --> 00:08:14,110
мы позволили бы только зарегистрированному пользователю, который вошел в систему для

106
00:08:14,110 --> 00:08:20,835
доступа к комментариям для конкретного блюда,

107
00:08:20,835 --> 00:08:25,990
мы позволим зарегистрированному пользователю публиковать комментарии.

108
00:08:25,990 --> 00:08:28,730
Мы уже настроили это в упражнении, поэтому,

109
00:08:28,730 --> 00:08:31,290
когда пользователь отправляет комментарий,

110
00:08:31,290 --> 00:08:34,150
мы гарантировали, что мы проверяем

111
00:08:34,150 --> 00:08:37,150
подлинность пользователя, а затем, когда комментарий опубликован,

112
00:08:37,150 --> 00:08:44,060
мы установили идентификатор автора для комментария, используя идентификатор пользователя.

113
00:08:44,060 --> 00:08:46,140
Итак, мы уже закончили это.

114
00:08:46,140 --> 00:08:48,625
Но теперь, кроме того,

115
00:08:48,625 --> 00:08:55,220
для операций ввода и удаления комментариев

116
00:08:55,220 --> 00:08:59,480
только пользователю, который отправил конкретный комментарий, будет

117
00:08:59,480 --> 00:09:04,180
разрешено делать операции ввода и удаления над своими комментариями.

118
00:09:04,180 --> 00:09:08,480
Любой другой пользователь не может изменить чужие комментарии.

119
00:09:08,480 --> 00:09:13,355
Аналогично, даже администратор не может изменить чужие комментарии

120
00:09:13,355 --> 00:09:14,960
или удалить чужой комментарий.

121
00:09:14,960 --> 00:09:18,850
Итак, это вторая часть этого задания, что ты будешь делать.

122
00:09:18,850 --> 00:09:22,910
Третья часть заключается в том, что администратор может запросить

123
00:09:22,910 --> 00:09:31,115
конечную точку /users и запросить список зарегистрированных пользователей,

124
00:09:31,115 --> 00:09:35,090
ни один другой обычный пользователь не может сделать этот запрос.

125
00:09:35,090 --> 00:09:38,550
Итак, это другое ограничение, которое мы введем туда.

126
00:09:38,550 --> 00:09:42,745
Теперь, чтобы убедиться, что пользователь является администратором,

127
00:09:42,745 --> 00:09:46,770
мы сначала проверим, что пользователь является зарегистрированным пользователем.

128
00:09:46,770 --> 00:09:51,470
Таким образом, функция проверки пользователя, которую мы уже реализовали в

129
00:09:51,470 --> 00:09:56,450
authenticate.js, должна применяться даже там, где вам нужно проверить наличие администратора.

130
00:09:56,450 --> 00:09:59,855
Во-первых, вы проверяете, что является проверенным пользователем, затем

131
00:09:59,855 --> 00:10:05,795
вы вводите другую функцию под названием VerifyAdmin в

132
00:10:05,795 --> 00:10:12,285
файле authenticate.js, которая будет проверять, что пользователь является администратором.

133
00:10:12,285 --> 00:10:15,190
Теперь, чтобы проверить, является ли пользователь администратором,

134
00:10:15,190 --> 00:10:19,900
все, что вам нужно сделать, это проверить rec.user, который находится

135
00:10:19,900 --> 00:10:24,855
на объекте запроса rec.user,

136
00:10:24,855 --> 00:10:28,325
проверьте, является ли флаг администратора истинным или нет.

137
00:10:28,325 --> 00:10:30,375
Если флаг admin истинный,

138
00:10:30,375 --> 00:10:39,315
вы разрешите нормальный процесс дальнейшего продвижения к [неслышному] произойдет.

139
00:10:39,315 --> 00:10:41,570
Если пользователь не является администратором,

140
00:10:41,570 --> 00:10:49,075
вы создадите ошибку и отправите сообщение об ошибке обратно на клиентскую сторону.

141
00:10:49,075 --> 00:10:53,945
Итак, вот как мы будем обрабатывать учетную запись пользователей администратора.

142
00:10:53,945 --> 00:11:03,165
Теперь, когда пользователь пытается изменить или удалить свои собственные комментарии,

143
00:11:03,165 --> 00:11:06,320
мы должны проверить, чтобы убедиться, что автор комментария тот

144
00:11:06,320 --> 00:11:10,245
же, что и пользователь, который пытается изменить комментарий.

145
00:11:10,245 --> 00:11:13,085
Теперь у rec.user также есть поле ID,

146
00:11:13,085 --> 00:11:16,860
поэтому вам нужно проверить это с полем автора комментария.

147
00:11:16,860 --> 00:11:18,255
Если эти два совпадают,

148
00:11:18,255 --> 00:11:22,390
то вы разрешите пользователю выполнять операции ввода или удаления.

149
00:11:22,390 --> 00:11:24,050
Если они не совпадают,

150
00:11:24,050 --> 00:11:31,190
вы не разрешите операции ввода или удаления для этого конкретного комментария.

151
00:11:31,190 --> 00:11:33,590
Так что это другой аспект, который вы собираетесь

152
00:11:33,590 --> 00:11:37,185
реализовать как часть вашего третьего задания.

153
00:11:37,185 --> 00:11:40,420
Давайте посмотрим, как все эти вещи работают

154
00:11:40,420 --> 00:11:44,500
с помощью Postman для выполнения различных операций на нашем сервере.

155
00:11:44,500 --> 00:11:46,545
Возвращаясь к Postman,

156
00:11:46,545 --> 00:11:49,725
позвольте мне сначала выполнить операцию GET на

157
00:11:49,725 --> 00:11:53,920
блюдах, чтобы просто проверить, что находится в моей базе данных.

158
00:11:53,920 --> 00:11:56,140
Итак, если я выполняю операцию GET на блюдах,

159
00:11:56,140 --> 00:12:00,270
обратите внимание, что я не помещаю никакой аутентификации в заголовок.

160
00:12:00,270 --> 00:12:02,500
Операция GET разрешена кем угодно.

161
00:12:02,500 --> 00:12:04,420
Итак, когда я выполняю операцию GET,

162
00:12:04,420 --> 00:12:13,985
я вижу, что у меня уже есть одно блюдо с комментарием, уже существующим в этом блюде.

163
00:12:13,985 --> 00:12:18,900
Этот комментарий уже был опубликован этим пользователем.

164
00:12:18,900 --> 00:12:23,895
Итак, у нас уже есть одно блюдо в системе.

165
00:12:23,895 --> 00:12:26,520
Так что, это прекрасно,

166
00:12:26,520 --> 00:12:28,405
я собираюсь удалить блюдо.

167
00:12:28,405 --> 00:12:29,875
Теперь, чтобы удалить блюдо,

168
00:12:29,875 --> 00:12:33,855
очевидно, что операция не может быть выполнена обычным пользователем.

169
00:12:33,855 --> 00:12:36,500
Итак, позвольте мне войти как,

170
00:12:36,500 --> 00:12:40,310
чтобы вы могли видеть, что я регистрируюсь как обычный пользователь.

171
00:12:40,310 --> 00:12:44,940
Итак, позвольте мне войти в систему как обычный пользователь.

172
00:12:44,940 --> 00:12:47,140
Поэтому, когда я войду в систему, я получу токен.

173
00:12:47,140 --> 00:12:49,725
Итак, я собираюсь скопировать этот токен и сохранить его.

174
00:12:49,725 --> 00:12:53,845
Теперь, когда у меня есть мой токен,

175
00:12:53,845 --> 00:12:58,770
позвольте мне выполнить операцию DELETE на блюдах.

176
00:12:58,770 --> 00:13:01,985
Итак, когда я перехожу к операции DELETE.

177
00:13:01,985 --> 00:13:07,370
Итак, позвольте мне выбрать этот GET, а затем выполнить операцию DELETE с посудой.

178
00:13:07,370 --> 00:13:13,440
В заголовке позвольте мне включить авторизацию здесь, и вы заметите,

179
00:13:13,440 --> 00:13:22,144
что, когда мы вставляем запрос, а затем отправляем авторизацию DELETE,

180
00:13:22,144 --> 00:13:27,325
вы заметите, что он немедленно возвращается с этим сообщением здесь,

181
00:13:27,325 --> 00:13:28,990
как вы можете видеть в предварительном просмотре,

182
00:13:28,990 --> 00:13:33,510
он говорит: «Вы не уполномочены выполнить эту операцию! «

183
00:13:33,510 --> 00:13:37,410
Тогда код ошибки 403 запрещен.

184
00:13:37,410 --> 00:13:41,540
Таким образом, это сообщение, сгенерированное

185
00:13:41,540 --> 00:13:46,470
функцией VerifyAdmin, которое вы собираетесь реализовать в рамках этого упражнения.

186
00:13:46,470 --> 00:13:49,720
Таким образом, если пользователь не является администратором,

187
00:13:49,720 --> 00:13:53,085
то это сообщение, которое будет

188
00:13:53,085 --> 00:13:57,880
генерировать ваш VerifyAdmin, и это не позволит запросу выйти за пределы этой точки.

189
00:13:57,880 --> 00:14:04,150
Итак, вы можете видеть, что я закрыл операцию DELETE.

190
00:14:04,150 --> 00:14:05,895
Итак, как ты это делаешь?

191
00:14:05,895 --> 00:14:11,925
В вашем коде вы видели, что для применения VerifyUser

192
00:14:11,925 --> 00:14:16,270
мы устанавливаем Authenticate.verifyUser в

193
00:14:16,270 --> 00:14:18,270
операциях POST, PUT и DELETE.

194
00:14:18,270 --> 00:14:22,105
Теперь вы можете связать промежуточное ПО один за другим.

195
00:14:22,105 --> 00:14:25,200
Таким образом, мы можем сказать Authenticate.VerifyUser запятая,

196
00:14:25,200 --> 00:14:28,905
а затем после этого вы можете сказать Authenticate.VerifyAdmin,

197
00:14:28,905 --> 00:14:32,190
чтобы применить VerifyAdmin сразу после VerifyUser.

198
00:14:32,190 --> 00:14:35,840
Таким образом, если вы хотите, чтобы операция была ограничена только администратором,

199
00:14:35,840 --> 00:14:39,520
вы сначала выполняете часть VerifyUser, а затем сразу после этого

200
00:14:39,520 --> 00:14:42,085
применяете промежуточное программное обеспечение VerifyAdmin.

201
00:14:42,085 --> 00:14:45,274
Сразу после этого. Итак, если эти две проверки

202
00:14:45,274 --> 00:14:49,615
успешно пройдут, то вы перейдете к выполнению операции.

203
00:14:49,615 --> 00:14:52,240
Если проверка VerifyAdmin завершилась неудачей,

204
00:14:52,240 --> 00:14:54,870
вы вернете это сообщение об ошибке, как вы видите

205
00:14:54,870 --> 00:14:57,995
здесь, а затем прервите операцию этой части.

206
00:14:57,995 --> 00:15:01,300
Таким образом, вы вернете следующую ошибку из своего VerifyAdmin,

207
00:15:01,300 --> 00:15:03,260
если пользователь не является администратором.

208
00:15:03,260 --> 00:15:08,100
Итак, я продемонстрировал вам, как вы собираетесь

209
00:15:08,100 --> 00:15:12,865
использовать учетную запись пользователей администратора для ограничения операций PUT

210
00:15:12,865 --> 00:15:15,285
, POST и DELETE.

211
00:15:15,285 --> 00:15:21,935
То же самое, операции POST и PUT также не будут разрешены ни на одной из этих n частей.

212
00:15:21,935 --> 00:15:26,360
Теперь позвольте мне продемонстрировать другой аспект здесь.

213
00:15:26,360 --> 00:15:28,710
Итак, вы видели, что там,

214
00:15:28,710 --> 00:15:30,450
когда мы выполняем операцию GET,

215
00:15:30,450 --> 00:15:37,570
вы видели, что уже есть комментарий, который был опубликован именем пользователя Jogesh,

216
00:15:37,570 --> 00:15:40,230
первого пользователя, который находится в моей системе.

217
00:15:40,230 --> 00:15:43,385
Теперь я собираюсь войти в систему как другой пользователь.

218
00:15:43,385 --> 00:15:53,080
Итак, я войду в свой второй аккаунт, который является Muppala, а затем, когда я вхожу в систему,

219
00:15:53,080 --> 00:15:54,175
я снова получаю токен.

220
00:15:54,175 --> 00:15:56,585
Итак, позвольте мне взять этот жетон здесь.

221
00:15:56,585 --> 00:15:58,645
Позвольте мне скопировать этот жетон.

222
00:15:58,645 --> 00:16:04,685
Теперь, что я собираюсь сделать, это сделать, я сделаю GET на блюдах localhost.

223
00:16:04,685 --> 00:16:12,520
Итак, позвольте мне сделать GET на блюдах localhost, чтобы показать вам конкретный комментарий внутри здесь.

224
00:16:12,520 --> 00:16:16,030
Итак, этот конкретный комментарий с этим идентификатором.

225
00:16:16,030 --> 00:16:17,640
То, что я собираюсь сделать, так это то,

226
00:16:17,640 --> 00:16:20,400
что я скопирую удостоверение тарелки.

227
00:16:20,400 --> 00:16:26,810
Я также собираюсь скопировать идентификатор комментария отсюда, и я собираюсь выполнить

228
00:16:26,810 --> 00:16:38,700
операцию DELETE на этом конкретном блюде

229
00:16:38,700 --> 00:16:42,615
и напомнить, что у нас есть косая

230
00:16:42,615 --> 00:16:50,980
черта комментариев, а затем этот конкретный идентификатор комментария.

231
00:16:50,980 --> 00:16:55,350
Теперь помните, что этот комментарий был опубликован этим именем пользователя,

232
00:16:55,350 --> 00:17:01,120
но теперь я вошел в себя как другой пользователь с другим именем пользователя.

233
00:17:01,120 --> 00:17:07,075
Итак, когда я сейчас выполняю операцию DELETE с помощью другой учетной записи,

234
00:17:07,075 --> 00:17:11,950
вы сразу заметите, что здесь написано:

235
00:17:11,950 --> 00:17:15,550
«Вы не уполномочены удалять этот комментарий! «

236
00:17:15,550 --> 00:17:18,970
Тогда он говорит 403, то же самое.

237
00:17:18,970 --> 00:17:24,205
Если вы попытаетесь выполнить операцию PUT для этого конкретного комментария, зарегистрированного в качестве другого пользователя

238
00:17:24,205 --> 00:17:30,010
, он скажет: «Вы не уполномочены обновлять этот комментарий!»

239
00:17:30,010 --> 00:17:35,340
Таким образом, как PUT, DELETE и UPDATE чужого комментария не разрешены.

240
00:17:35,340 --> 00:17:41,855
Итак, теперь позвольте мне войти в качестве администратора в этот момент, а затем позвольте мне попытаться удалить этот

241
00:17:41,855 --> 00:17:50,510
конкретный комментарий, и вы увидите, что будет сгенерировано одно и то же сообщение.

242
00:17:50,510 --> 00:17:55,890
Таким образом, администратор также не может удалять или обновлять чужие комментарии.

243
00:17:55,890 --> 00:17:57,600
Итак, чтобы войти в качестве администратора,

244
00:17:57,600 --> 00:18:02,785
позвольте мне войти в POST здесь, а затем позвольте мне войти в качестве администратора.

245
00:18:02,785 --> 00:18:08,585
Теперь помните, что эти токены будут действительны в течение 33,600 секунд.

246
00:18:08,585 --> 00:18:12,620
Таким образом, вы можете сохранить эти три токена, которые вы генерируете для трех пользователей.

247
00:18:12,620 --> 00:18:16,270
Таким образом, вам не нужно продолжать входить в систему как этот конкретный пользователь.

248
00:18:16,270 --> 00:18:20,180
Пока вы используете правильный токен в заголовке,

249
00:18:20,180 --> 00:18:25,670
ваши операции будут выполнять просто отлично идентифицируя трех разных пользователей.

250
00:18:25,670 --> 00:18:28,655
Итак, позвольте мне войти в качестве администратора здесь.

251
00:18:28,655 --> 00:18:30,670
Поэтому, когда я вхожу в качестве администратора,

252
00:18:30,670 --> 00:18:31,680
я получаю токен здесь.

253
00:18:31,680 --> 00:18:34,930
Итак, я собираюсь скопировать и сохранить этот токен.

254
00:18:35,010 --> 00:18:40,800
Просто помните, какой токен принадлежит кому, когда вы делаете копию этого.

255
00:18:40,800 --> 00:18:45,430
Теперь, возвращаясь к этому, удалите операцию комментария.

256
00:18:45,430 --> 00:18:54,575
Я собираюсь войти в заголовок, а затем я собираюсь изменить это на токен для

257
00:18:54,575 --> 00:19:00,980
администратора, а затем попытаться выполнить ту же операцию DELETE, а затем вы видите,

258
00:19:00,980 --> 00:19:08,420
что даже администратор не уполномочен удалять комментарий, размещенный другим пользователем.

259
00:19:08,420 --> 00:19:10,480
Это вполне приемлемо.

260
00:19:10,480 --> 00:19:13,095
Но давайте попробуем удалить тот же комментарий,

261
00:19:13,095 --> 00:19:15,255
этим пользователем, который создал этот

262
00:19:15,255 --> 00:19:18,425
комментарий, и вы увидите, что это может быть успешно сделано.

263
00:19:18,425 --> 00:19:20,715
Итак, давайте выполним эту операцию.

264
00:19:20,715 --> 00:19:24,720
Поэтому, чтобы сделать это, я собираюсь вернуться и получить токен, который у

265
00:19:24,720 --> 00:19:30,345
меня есть для первого пользователя, а затем изменить поле Авторизация.

266
00:19:30,345 --> 00:19:33,260
Теперь, для этой операции DELETE,

267
00:19:33,260 --> 00:19:35,860
я собираюсь изменить это на носителя,

268
00:19:35,860 --> 00:19:42,400
а затем это токен для первого пользователя с именем пользователя Jogesh.

269
00:19:42,400 --> 00:19:46,100
Поэтому, когда я попытаюсь удалить этот комментарий,

270
00:19:46,100 --> 00:19:50,850
вы заметите, что комментарий теперь успешно удален.

271
00:19:50,850 --> 00:19:53,710
Таким образом, как вы можете видеть из шагов,

272
00:19:53,710 --> 00:19:57,830
комментарий может быть удален только пользователем, который создал этот комментарий.

273
00:19:57,830 --> 00:19:59,120
Теперь, следующий шаг,

274
00:19:59,120 --> 00:20:02,345
когда мы делаем операцию DELETE на тарелке,

275
00:20:02,345 --> 00:20:07,120
мы видели ранее, что если мы сделали операцию DELETE как обычный пользователь,

276
00:20:07,120 --> 00:20:09,400
вы получаете сообщение с надписью:

277
00:20:09,400 --> 00:20:12,010
«Вы не уполномочены выполнять эту операцию!»

278
00:20:12,010 --> 00:20:16,670
Итак, я собираюсь изменить этот токен на токен администратора, а затем

279
00:20:16,670 --> 00:20:21,425
показать вам, что администратор может выполнить операцию DELETE на блюдах и горшочке.

280
00:20:21,425 --> 00:20:23,480
Итак, перейдя в этот запрос,

281
00:20:23,480 --> 00:20:30,550
позвольте мне изменить токен на токен для пользователя администратора.

282
00:20:30,550 --> 00:20:34,765
Таким образом, когда я выполняю операцию DELETE как пользователь администратора,

283
00:20:34,765 --> 00:20:37,375
вы заметите, что операция DELETE

284
00:20:37,375 --> 00:20:41,905
успешна, а затем ответите обратно с сообщением здесь.

285
00:20:41,905 --> 00:20:45,715
Теперь, когда я делаю GET на конечной точке блюд,

286
00:20:45,715 --> 00:20:52,515
вы заметите, что операции GET показывают, что мои блюда были опущены.

287
00:20:52,515 --> 00:20:59,285
Теперь другая операция, которую вы также будете реализовывать в этом назначении,

288
00:20:59,285 --> 00:21:05,670
заключается в том, что мы можем сделать операцию GET на конечной точке пользователей косой черты.

289
00:21:05,670 --> 00:21:09,285
Таким образом, когда вы выполняете операцию GET на конечной точке пользователей,

290
00:21:09,285 --> 00:21:12,690
вы заметите, что если вы не являетесь авторизованным пользователем,

291
00:21:12,690 --> 00:21:16,450
он скажет, что вы не уполномочены выполнять эту операцию.

292
00:21:16,450 --> 00:21:20,850
Итак, локальный хост: 3000/пользователи/конечная точка,

293
00:21:20,850 --> 00:21:27,355
теперь вы разрешаете это выполнять только администратор.

294
00:21:27,355 --> 00:21:29,265
Итак, если обычный пользователь,

295
00:21:29,265 --> 00:21:32,420
при входе в систему как обычный пользователь с заголовком,

296
00:21:32,420 --> 00:21:36,510
вам не будет разрешено выполнять эту операцию.

297
00:21:36,510 --> 00:21:42,390
Теперь позвольте мне изменить этот токен на токен

298
00:21:42,390 --> 00:21:45,345
от администратора, а затем вы увидите, что

299
00:21:45,345 --> 00:21:48,460
администратору будет разрешено выполнять эту операцию.

300
00:21:48,460 --> 00:21:50,135
Итак, перейдя к GET,

301
00:21:50,135 --> 00:21:55,600
позвольте мне изменить этот токен на токен для

302
00:21:55,600 --> 00:22:02,980
пользователя администратора, а затем, когда я выполняю операцию GET, он возвращается.

303
00:22:02,980 --> 00:22:07,945
Как вы можете видеть, три пользователя, которые зарегистрированы в моей системе,

304
00:22:07,945 --> 00:22:11,015
он показывает пользователя номер один,

305
00:22:11,015 --> 00:22:13,950
пользователь номер два и пользователь номер три.

306
00:22:13,950 --> 00:22:17,530
Конечно, обратите внимание, что хэш и соль удаляются,

307
00:22:17,530 --> 00:22:21,965
когда сообщение возвращается сервером на стороне клиента.

308
00:22:21,965 --> 00:22:25,490
Таким образом, информация о хэше и соли никогда не будет раскрыта снаружи.

309
00:22:25,490 --> 00:22:28,755
Таким образом, Mongos автоматически позаботится о фильтрации

310
00:22:28,755 --> 00:22:32,580
этой информации, прежде чем он отправит обратно информацию пользователя.

311
00:22:32,580 --> 00:22:35,890
Итак, потому что вы не должны раскрывать

312
00:22:35,890 --> 00:22:39,160
информацию о хэше и соли внешнему миру.

313
00:22:39,160 --> 00:22:44,510
Таким образом, это информация о трех учетных записях пользователей, которая возвращается.

314
00:22:44,510 --> 00:22:47,835
Таким образом, это возвращается только в том случае, если вы выполняете операцию GET

315
00:22:47,835 --> 00:22:51,900
на конечной точке пользователей косой черты в качестве пользователя администратора.

316
00:22:51,900 --> 00:22:56,295
Если вы выполняете тот же запрос, что и любой другой пользователь,

317
00:22:56,295 --> 00:22:58,055
это не будет разрешено.

318
00:22:58,055 --> 00:23:01,065
Таким образом, снова вы проверите сначала

319
00:23:01,065 --> 00:23:05,040
VerifyUser, а затем проверьте VerifyAdmin и только если это администратор,

320
00:23:05,040 --> 00:23:08,940
то эта операция может быть выполнена на этой конечной точке.

321
00:23:08,940 --> 00:23:15,535
Таким образом, это все различные задачи, которые вы будете делать в рамках этого задания.

322
00:23:15,535 --> 00:23:22,990
Подробная информация о том, как это необходимо сделать, документирована в инструкциях по назначению.

323
00:23:22,990 --> 00:23:27,875
Итак, ознакомьтесь с инструкциями, прежде чем приступать к выполнению третьего задания.

324
00:23:27,875 --> 00:23:32,380
Получайте удовольствие, выполняя третье задание.