1
00:00:00,000 --> 00:00:04,470
[MUSIC]

2
00:00:04,470 --> 00:00:10,326
Сервер Express REST API, который мы реализовали в предыдущем

3
00:00:10,326 --> 00:00:17,750
модуле, позволяет любому пользователю выполнять любые операции GET или POST или DELETE.

4
00:00:17,750 --> 00:00:21,360
Отсутствует контроль над тем, кто может выполнять эту операцию.

5
00:00:21,360 --> 00:00:22,350
Это означает, что

6
00:00:22,350 --> 00:00:27,180
если вы запускаете такой сервер, то любой может войти на ваш сервер и

7
00:00:27,180 --> 00:00:33,420
начать манипулировать информацией, которая присутствует в вашей базе данных.

8
00:00:33,420 --> 00:00:36,578
Очевидно, что это опасная ситуация.

9
00:00:36,578 --> 00:00:40,380
Способ, которым должен быть реализован сервер, заключается в том, что

10
00:00:40,380 --> 00:00:44,330
вам нужно иметь какое-то ограничение на то,

11
00:00:44,330 --> 00:00:48,660
какие типы пользователей будут разрешены для выполнения каких видов операций.

12
00:00:48,660 --> 00:00:51,090
Поэтому, возможно, вы разрешите и

13
00:00:51,090 --> 00:00:54,650
авторизованному пользователю только выполнять операции GET.

14
00:00:54,650 --> 00:01:00,040
Так, например, если вы хотите, чтобы гость мог видеть информацию

15
00:01:00,040 --> 00:01:04,860
о блюдах в вашем ресторане или меню вашего ресторана и

16
00:01:04,860 --> 00:01:07,250
так далее, это вполне приемлемо.

17
00:01:07,250 --> 00:01:11,699
Но вы можете разрешить только администратору войти и

18
00:01:11,699 --> 00:01:17,780
изменить информацию о блюде или удалить блюдо из меню.

19
00:01:17,780 --> 00:01:23,448
А также обновите существующее блюдо в меню, или акцию,

20
00:01:23,448 --> 00:01:29,062
или информацию о лидерах на вашей стороне сервера.

21
00:01:29,062 --> 00:01:34,810
Теперь вы также можете иметь другую группу пользователей, которые будут зарегистрированы пользователи,

22
00:01:34,810 --> 00:01:39,980
которым может быть разрешено сохранить некоторые из своих блюд в качестве своих любимых блюд,

23
00:01:39,980 --> 00:01:44,290
и только они смогут манипулировать списком своих любимых блюд.

24
00:01:44,290 --> 00:01:47,850
Таким образом, это еще один уровень авторизации или

25
00:01:47,850 --> 00:01:49,940
аутентификации, который вам нужно выполнить.

26
00:01:49,940 --> 00:01:53,400
Таким образом, у вас есть разные классы пользователей, а

27
00:01:53,400 --> 00:01:57,820
также, в зависимости от того, какие операции им разрешено выполнять.

28
00:01:57,820 --> 00:02:01,880
Таким образом, все это означает, что вам нужна какая-то безопасность, которая будет

29
00:02:01,880 --> 00:02:03,840
встроена в вашу серверную сторону.

30
00:02:03,840 --> 00:02:07,970
Мы рассмотрим, как мы можем аутентифицировать пользователей, а

31
00:02:07,970 --> 00:02:13,110
затем определим, какой пользователь этот клиент.

32
00:02:13,110 --> 00:02:15,410
И затем, в зависимости от типа пользователя,

33
00:02:15,410 --> 00:02:19,360
вы можете позволить пользователю выполнять определенные виды операций.

34
00:02:19,360 --> 00:02:24,630
Мы начнем с базового понимания этого, что мы называем

35
00:02:24,630 --> 00:02:30,860
обычной аутентификацией на стороне сервера для

36
00:02:30,860 --> 00:02:36,940
клиента, а затем, основываясь на этом во всем остальном модуле.

37
00:02:36,940 --> 00:02:42,030
И тогда в конце этого модуля мы получим механизм

38
00:02:42,030 --> 00:02:46,170
, тем самым позволяя пользователям регистрироваться самостоятельно.

39
00:02:46,170 --> 00:02:50,220
И зарегистрированные пользователи могут выполнять определенные операции

40
00:02:50,220 --> 00:02:53,930
, которые незарегистрированный пользователь не может, и так далее.

41
00:02:53,930 --> 00:02:57,320
Таким образом, мы будем накладывать

42
00:02:57,320 --> 00:03:01,990
различные виды контроля доступа для различных операций на стороне сервера на основе типа пользователя.

43
00:03:01,990 --> 00:03:04,930
Таким образом, это задает вам перспективу, или,

44
00:03:04,930 --> 00:03:09,830
скорее, представление о том, что вы столкнетесь в этом модуле.

45
00:03:09,830 --> 00:03:12,450
Начнем с обычной аутентификации,

46
00:03:12,450 --> 00:03:18,450
самого базового механизма, который позволит нам аутентифицировать пользователей.

47
00:03:19,970 --> 00:03:25,173
Обычная аутентификация в HTTP - это очень простой механизм,

48
00:03:25,173 --> 00:03:28,782
который будет запрашивать у пользователя имя пользователя и

49
00:03:28,782 --> 00:03:32,720
пароль, которые будут отправлены с запросом.

50
00:03:32,720 --> 00:03:35,180
И есть определенная структура

51
00:03:35,180 --> 00:03:39,920
о том, как эта информация будет передаваться от клиента на серверную сторону.

52
00:03:39,920 --> 00:03:45,060
Таким образом, это вопрос, основная аутентификация доступа, которую поддерживает HTTP,

53
00:03:45,060 --> 00:03:49,860
это вопрос, который позволит серверу оспорить клиента и попросить

54
00:03:49,860 --> 00:03:53,110
имя пользователя и пароль, которые будут отправлены клиентом.

55
00:03:53,110 --> 00:03:57,714
Таким образом, сервер может вызвать клиента для проверки подлинности, введя эту

56
00:03:57,714 --> 00:03:59,140
информацию.

57
00:03:59,140 --> 00:04:01,880
Клиент должен отправить имя пользователя и

58
00:04:01,880 --> 00:04:05,440
пароль в ответ на вызов со стороны сервера.

59
00:04:05,440 --> 00:04:09,870
Таким образом, каждое сообщение запроса, исходящее от клиента,

60
00:04:09,870 --> 00:04:13,870
должно включать закодированную форму имени пользователя и

61
00:04:13,870 --> 00:04:19,700
пароля в заголовке запроса, который идет от клиента на сторону сервера.

62
00:04:19,700 --> 00:04:22,229
Поэтому, когда сервер получает запрос,

63
00:04:22,229 --> 00:04:27,009
сервер извлечет эту информацию из заголовка запроса клиента.

64
00:04:27,009 --> 00:04:31,831
И затем используйте это для аутентификации клиента, прежде чем

65
00:04:31,831 --> 00:04:37,390
разрешить доступ к различным операциям на стороне сервера.

66
00:04:37,390 --> 00:04:40,850
Итак, как работает эта аутентификация?

67
00:04:40,850 --> 00:04:44,450
Если клиент отправляет запрос на сервер, и

68
00:04:44,450 --> 00:04:50,150
этот запрос клиента не включает формирование авторизации, сервер

69
00:04:50,150 --> 00:04:55,160
будет оспаривать клиента, он просит клиента отправить эту информацию.

70
00:04:55,160 --> 00:04:58,100
Сервер бросает вызов клиенту,

71
00:04:58,100 --> 00:05:01,900
включив заголовок в входящее ответное сообщение.

72
00:05:01,900 --> 00:05:06,410
Заголовок с типом как WWW-Authenticate, а

73
00:05:06,410 --> 00:05:11,843
затем вторая часть, где он указывает тип, где он будет

74
00:05:11,843 --> 00:05:17,500
указывать, какой тип проверки подлинности клиент должен отправить.

75
00:05:17,500 --> 00:05:21,990
И мы начнем с понимания базовой аутентификации здесь.

76
00:05:21,990 --> 00:05:26,400
А также обратите внимание, что ответное сообщение будет содержать код ошибки 401,

77
00:05:27,570 --> 00:05:31,270
который является несанкционированным, что означает несанкционированный.

78
00:05:31,270 --> 00:05:35,470
Поэтому, когда ответ возвращается с серверной стороны, клиент

79
00:05:35,470 --> 00:05:41,300
в ответ на этот ответ приходит, клиент должен будет отправить свой запрос,

80
00:05:41,300 --> 00:05:49,550
включая конкретное поле заголовка в сообщении запроса авторизации типа.

81
00:05:49,550 --> 00:05:55,250
И это поле заголовка авторизации будет содержать некоторую информацию.

82
00:05:55,250 --> 00:06:00,440
Для базовой аутентификации, эта информация будет в форме,

83
00:06:00,440 --> 00:06:03,900
как первое слово здесь, будет Basic.

84
00:06:03,900 --> 00:06:11,410
И затем следует пробел здесь, а затем строка в кодировке Base64 здесь.

85
00:06:11,410 --> 00:06:15,358
Эта кодированная строка Base64 кодирует имя пользователя и

86
00:06:15,358 --> 00:06:21,350
пароль в определенном формате, а затем включает в заголовок.

87
00:06:21,350 --> 00:06:25,479
Теперь вы говорите, что если вы отправляете сообщение запроса, подобное этому,

88
00:06:25,479 --> 00:06:29,397
включая это, в заголовке, тогда кто-нибудь посередине.

89
00:06:29,397 --> 00:06:33,538
Так что если вы знаете что-нибудь о безопасности и о том,

90
00:06:33,538 --> 00:06:39,927
как люди в середине атаки могут быть запущены, то очевидно, что

91
00:06:39,927 --> 00:06:44,777
это может быть извлечено злоумышленником между ними,

92
00:06:44,777 --> 00:06:49,590
а затем может быть использовано для подделки реального клиента.

93
00:06:49,590 --> 00:06:52,720
Опять же, в данный момент мы не будем вдаваться в этот вопрос.

94
00:06:52,720 --> 00:06:57,470
Когда я расскажу о HTTPS в следующем модуле,

95
00:06:57,470 --> 00:07:00,880
я вернусь, чтобы рассмотреть эту проблему немного более подробно.

96
00:07:00,880 --> 00:07:06,060
Но на данный момент информация в заголовке будет отправлена

97
00:07:07,880 --> 00:07:11,930
без шифрования в заголовке в данный момент.

98
00:07:11,930 --> 00:07:15,460
Теперь еще одна причина, по которой я это делаю, заключается в том, что мы можем фактически посмотреть

99
00:07:15,460 --> 00:07:20,150
на заголовок напрямую, а затем увидеть эту информацию в самом заголовке.

100
00:07:20,150 --> 00:07:25,401
Таким образом, когда клиент отправляет этот запрос, сервер извлечет

101
00:07:25,401 --> 00:07:30,930
информацию из этого заголовка авторизации в заголовке запроса.

102
00:07:30,930 --> 00:07:35,078
Затем используйте эту информацию, чтобы проверить, является ли это

103
00:07:35,078 --> 00:07:37,670
авторизованным запросом клиента или нет.

104
00:07:37,670 --> 00:07:40,412
Теперь, конечно, ваш следующий вопрос будет:

105
00:07:40,412 --> 00:07:44,490
что именно содержит этот заголовок авторизации?

106
00:07:44,490 --> 00:07:48,350
Сам заголовок авторизации строится следующим образом.

107
00:07:48,350 --> 00:07:52,180
Если у вас есть имя пользователя и пароль, это две

108
00:07:52,180 --> 00:07:55,730
части информации, которые вы будете использовать для аутентификации клиента.

109
00:07:55,730 --> 00:08:01,330
Таким образом, имя пользователя и пароль будут объединены в одну строку,

110
00:08:01,330 --> 00:08:06,910
сказав имя пользователя и двоеточие, а также сам пароль.

111
00:08:06,910 --> 00:08:09,860
Таким образом, строка имени пользователя, двоеточие и

112
00:08:09,860 --> 00:08:16,210
пароль будут объединены вместе в целую строку здесь.

113
00:08:16,210 --> 00:08:22,994
Эта результирующая строка, которую мы получаем здесь, кодируется с помощью кодирования Base64.

114
00:08:22,994 --> 00:08:27,344
Если вы знаете о том, как кодирование выполняется основы для кодирования,

115
00:08:27,344 --> 00:08:32,390
преобразуйте его в заголовок ASCII, как показано в этом примере,

116
00:08:32,390 --> 00:08:36,195
так что это не что иное, как строка заголовков ASCII.

117
00:08:36,195 --> 00:08:39,545
Теперь, если вы мало знаете о базовой жесткой кодировке, не беспокойтесь об этом,

118
00:08:39,545 --> 00:08:44,325
это не влияет на ваше понимание того, что здесь происходит.

119
00:08:44,325 --> 00:08:47,090
Таким образом, эти строки в кодировке Basic64, поэтому

120
00:08:47,090 --> 00:08:51,950
эта конкретная информация кодируется в такую строку, а

121
00:08:51,950 --> 00:08:57,090
затем заключена в заголовок запроса, идущий от клиента на сервер.

122
00:08:57,090 --> 00:09:02,143
Сам заголовок запроса имеет тип авторизации,

123
00:09:02,143 --> 00:09:07,194
а затем фактическое значение здесь, которое говорит:

124
00:09:07,194 --> 00:09:13,774
Basic, и пробел здесь, и строка в кодировке Base64 здесь.

125
00:09:13,774 --> 00:09:20,034
Таким образом, когда это будет получено нашим сервером, сервер извлекает эту информацию,

126
00:09:20,034 --> 00:09:25,059
а затем извлекает имя пользователя и пароль,

127
00:09:25,059 --> 00:09:31,620
а затем проверяет, соответствует ли это авторизованному пользователю или нет на стороне сервера.

128
00:09:31,620 --> 00:09:36,917
Чтобы помочь вам лучше понять, как мы на самом деле организуем экспресс-приложение

129
00:09:36,917 --> 00:09:42,211
и как осуществляется сама аутентификация, как мы узнали ранее,

130
00:09:42,211 --> 00:09:47,520
сами экспресс-приложения организованы в набор промежуточного программного обеспечения.

131
00:09:47,520 --> 00:09:51,690
И способ работы экспресс-приложения заключается в том, что промежуточное программное обеспечение

132
00:09:51,690 --> 00:09:55,630
применяется к запросу и ответному сообщению

133
00:09:55,630 --> 00:10:00,940
в том порядке, в котором оно объявлено в моем экспресс-приложении.

134
00:10:00,940 --> 00:10:05,290
Поэтому, если у вас есть express.use, а

135
00:10:05,290 --> 00:10:09,740
затем у вас есть первый, говорящий на статическом сервере, затем после этого

136
00:10:09,740 --> 00:10:13,220
у вас есть другое промежуточное программное обеспечение, а затем у вас есть другое промежуточное программное обеспечение.

137
00:10:13,220 --> 00:10:18,560
Последовательность, в которой они объявлены в файле app.js express

138
00:10:18,560 --> 00:10:23,600
servers, это точная последовательность, в которой будет применено промежуточное программное обеспечение.

139
00:10:23,600 --> 00:10:29,124
Таким образом, входящий запрос с серверной стороны, как вы вспоминаете в своем

140
00:10:29,124 --> 00:10:34,690
экспресс-приложении, входящий запрос рассматривается как объект запроса.

141
00:10:34,690 --> 00:10:39,050
Объект ответа - это то, что создает экспресс-сервер, а

142
00:10:39,050 --> 00:10:43,310
затем следующий позволяет перейти к следующему промежуточному программному обеспечению

143
00:10:43,310 --> 00:10:45,910
, которое вы собираетесь применять, и так далее.

144
00:10:45,910 --> 00:10:52,400
Итак, входящий запрос, подобный этому, когда он приходит, применяется первое промежуточное программное обеспечение.

145
00:10:52,400 --> 00:10:56,164
И затем, как только это промежуточное программное обеспечение преобразовало как запрос

146
00:10:56,164 --> 00:11:00,680
, так и ответ, оно переходит к следующему промежуточному программному обеспечению, которое затем применяется к нему.

147
00:11:00,680 --> 00:11:03,940
Например, мы увидели, что сначала применили Морган,

148
00:11:03,940 --> 00:11:06,930
затем применили парсер тела к промежуточному программному обеспечению.

149
00:11:06,930 --> 00:11:12,930
Таким образом, они, должно быть, уже преобразовали запрос и объекты ответа.

150
00:11:12,930 --> 00:11:17,440
И после этого мы можем включить промежуточное программное обеспечение аутентификации на месте.

151
00:11:17,440 --> 00:11:22,260
Промежуточное программное обеспечение аутентификации будет аутентифицировать запрос.

152
00:11:22,260 --> 00:11:26,950
Теперь, поэтому, если вы используете обычную аутентификацию, ваш запрос

153
00:11:26,950 --> 00:11:31,970
должен содержать в заголовке заголовок авторизации, который там находится.

154
00:11:31,970 --> 00:11:36,260
Таким образом, заголовок авторизации будет извлечен промежуточным программным обеспечением аутентификации,

155
00:11:36,260 --> 00:11:40,180
а затем проверен, чтобы увидеть, авторизован ли пользователь.

156
00:11:40,180 --> 00:11:46,099
И если промежуточное программное обеспечение аутентификации обнаруживает, что вы авторизованный пользователь,

157
00:11:46,099 --> 00:11:50,515
вам будет разрешено перейти к следующему набору

158
00:11:50,515 --> 00:11:54,427
промежуточного программного обеспечения, который следует за шагом аутентификации.

159
00:11:54,427 --> 00:11:58,510
И ваши записи будут обработаны последующим промежуточным программным обеспечением.

160
00:11:58,510 --> 00:11:59,519
Но с другой стороны,

161
00:11:59,519 --> 00:12:04,422
если ваше промежуточное программное обеспечение аутентификации решит, что вы не являетесь авторизованным пользователем,

162
00:12:04,422 --> 00:12:09,197
то промежуточное программное обеспечение аутентификации приведет вас по другому пути.

163
00:12:09,197 --> 00:12:13,975
А затем сгенерировать ошибку, а затем отправить

164
00:12:13,975 --> 00:12:19,368
соответствующий ответ об ошибке на эту клиентскую сторону и

165
00:12:19,368 --> 00:12:24,010
будет перенаправлен в обработчик ошибок.

166
00:12:24,010 --> 00:12:28,450
Таким образом, это перенаправление в обработчик ошибок будет сделано путем вызова Next

167
00:12:28,450 --> 00:12:32,490
с ошибкой в качестве параметра для этого Next здесь.

168
00:12:32,490 --> 00:12:38,240
Таким образом, Next именно это Next, что мы видим в ресурсе запроса Next здесь.

169
00:12:38,240 --> 00:12:42,760
И поэтому это приведет вас к обработчику ошибок,

170
00:12:42,760 --> 00:12:48,170
который будет обрабатывать ошибку, а затем отправлять сообщение об ошибке обратно на клиентскую сторону,

171
00:12:48,170 --> 00:12:51,820
указывая на сбой аутентификации.

172
00:12:51,820 --> 00:12:56,720
Таким образом, ваша типичная базовая авторизация или обычная

173
00:12:56,720 --> 00:13:03,435
аутентификация работает в вашем серверном приложении.

174
00:13:03,435 --> 00:13:08,305
Поняв это, давайте перейдем к упражнению, где мы

175
00:13:08,305 --> 00:13:13,176
будем реализовывать базовую аутентификацию в нашем приложении и

176
00:13:13,176 --> 00:13:15,717
посмотрим, как она аутентифицирует пользователей.

177
00:13:15,717 --> 00:13:17,952
[ МУЗЫКА]