1
00:00:00,000 --> 00:00:04,746
[МУЗЫКА]

2
00:00:04,746 --> 00:00:08,050
Давайте поговорим на каком-то языке CORS.

3
00:00:08,050 --> 00:00:11,500
Что именно такое совместное использование результатов перекрестного происхождения и

4
00:00:11,500 --> 00:00:15,325
почему это актуально, когда мы смотрим на веб-приложения и

5
00:00:15,325 --> 00:00:21,010
гипермобильные приложения, как мы делали в этой специализации?

6
00:00:21,010 --> 00:00:25,260
Как вы понимаете, большинство веб-страниц теперь тянут данные со

7
00:00:25,260 --> 00:00:29,790
многих разных сайтов, чтобы построить веб-страницу.

8
00:00:29,790 --> 00:00:38,470
Теперь, чтобы навязать строгую политику доступа к ресурсам с разных сайтов, одна и

9
00:00:38,470 --> 00:00:44,220
та же политика происхождения была навязана многими браузерами.

10
00:00:44,220 --> 00:00:49,410
Мы поговорим немного об этом более подробно в следующих нескольких слайдах, но

11
00:00:49,410 --> 00:00:55,950
в контексте фреймворков, которые мы обсуждали в этой конкретной

12
00:00:55,950 --> 00:01:00,640
специализации, таких как Angular, Ionic и NativeScript,

13
00:01:00,640 --> 00:01:05,650
многие из них будут включать скрипты, JavaScript код,

14
00:01:05,650 --> 00:01:11,220
который может быть доступ к ресурсам с разных сайтов.

15
00:01:11,220 --> 00:01:16,790
И именно здесь проблема CORS возникает очень легко.

16
00:01:16,790 --> 00:01:22,290
Давайте посмотрим, как мы рассмотрим эту проблему более подробно в этой лекции и

17
00:01:22,290 --> 00:01:24,050
упражнении, которое следует за ней.

18
00:01:25,940 --> 00:01:31,446
Я кратко сослался на политику того же происхождения, что я начал эту лекцию.

19
00:01:31,446 --> 00:01:36,510
Теперь политика одного происхождения представляет собой модель безопасности веб-приложения,

20
00:01:36,510 --> 00:01:40,170
которая ограничивает

21
00:01:40,170 --> 00:01:45,380
взаимодействие документа или скрипта, загруженного из одного источника, с ресурсами из другого источника.

22
00:01:45,380 --> 00:01:50,270
Цель этого состоит в том, чтобы изолировать потенциально вредоносные документы.

23
00:01:50,270 --> 00:01:54,940
Теперь, очевидно, когда у вас есть веб-страница, которая включает в себя скрипт,

24
00:01:54,940 --> 00:02:00,900
код JavaScript, который может получить доступ к ресурсам из другого места,

25
00:02:00,900 --> 00:02:05,185
потенциально вредоносный код может быть введен на вашу веб-страницу и

26
00:02:05,185 --> 00:02:12,800
таким образом получить доступ к другому происхождению, чем от того, где ваша веб-страница получена.

27
00:02:12,800 --> 00:02:17,220
Теперь, по этой причине многие браузеры навязывают эту политику одного и того же происхождения.

28
00:02:17,220 --> 00:02:22,230
Теперь, когда мы говорим об одном происхождении, как мы можем указать происхождение?

29
00:02:22,230 --> 00:02:28,540
Теперь в этом контексте источник для любого ресурса определяется тремя кортежами.

30
00:02:28,540 --> 00:02:32,980
Во-первых, протокол, используемый для доступа к ресурсу.

31
00:02:32,980 --> 00:02:39,410
Во-вторых, имя хоста ресурса или домен этого ресурса.

32
00:02:39,410 --> 00:02:43,480
И в-третьих, номер порта, с которого осуществляется доступ к этому ресурсу.

33
00:02:43,480 --> 00:02:48,700
Так мы определяем происхождение любого ресурса.

34
00:02:48,700 --> 00:02:53,626
Ресурсом в этом случае может быть html-страница, изображение,

35
00:02:53,626 --> 00:03:00,720
данные JSON, получаемые из конечной точки REST API, и многое другое.

36
00:03:00,720 --> 00:03:05,410
Чтобы подробнее остановиться на политике одного происхождения, давайте рассмотрим пример.

37
00:03:05,410 --> 00:03:12,315
Предположим, что у нас есть веб-страница, которая загружается с этого сайта, перечисленных здесь

38
00:03:12,315 --> 00:03:17,330
, www.abc.com, и в папке xyz, и

39
00:03:17,330 --> 00:03:21,210
page.html загружается здесь.

40
00:03:21,210 --> 00:03:26,890
Эта страница может включать ссылки или даже код JavaScript, который может

41
00:03:26,890 --> 00:03:33,200
выдавать XMLHttpRequest другим ресурсам на веб-странице.

42
00:03:33,200 --> 00:03:38,310
Теперь, в этом случае, если мы попытаемся получить доступ к другому URL,

43
00:03:38,310 --> 00:03:42,690
например, первый из перечисленных здесь, который, очевидно, вы видите

44
00:03:42,690 --> 00:03:47,860
из того же сайта, но из другой папки.

45
00:03:47,860 --> 00:03:51,820
Это приемлемо, поскольку источник, в данном случае

46
00:03:51,820 --> 00:03:55,420
используемый протокол и номер порта, остается прежним.

47
00:03:55,420 --> 00:04:00,660
Таким образом, это приемлемо для доступа к этому ресурсу.

48
00:04:00,660 --> 00:04:05,470
Аналогично во втором случае, мы можем иметь под

49
00:04:07,040 --> 00:04:10,570
несколько уровней подпапок ресурс, к которому обращаются.

50
00:04:10,570 --> 00:04:15,850
Но опять же, поскольку их происхождение остается прежним, что приемлемо.

51
00:04:15,850 --> 00:04:18,260
Но давайте посмотрим на третий пример здесь.

52
00:04:18,260 --> 00:04:23,930
В этом примере мы видим, что мы пытаемся получить доступ к ресурсу здесь с

53
00:04:23,930 --> 00:04:31,230
протоколом https, который, очевидно, нарушает принцип

54
00:04:31,230 --> 00:04:35,580
того же происхождения, потому что мы используем другой протокол для доступа к этому ресурсу в данный момент.

55
00:04:35,580 --> 00:04:39,030
Так что в данном случае это будет считаться неудачей.

56
00:04:39,030 --> 00:04:44,840
Четвертый случай - это когда мы обращаемся к ресурсу с другим номером порта.

57
00:04:44,840 --> 00:04:50,300
И пятый случай, когда мы получаем доступ к ресурсу на другом хосте.

58
00:04:50,300 --> 00:04:54,830
Теперь все эти три будут помечены как недействительные или не

59
00:04:54,830 --> 00:04:58,110
могут быть доступны в рамках этой политики одного и того же происхождения.

60
00:04:58,110 --> 00:05:02,710
Поэтому, если вы навязываете политику одного происхождения для доступа, например, из

61
00:05:02,710 --> 00:05:10,970
вашего XMLHttpRequest, последние три не будут разрешены в этом случае.

62
00:05:10,970 --> 00:05:16,270
Но, конечно, есть много ситуаций, когда этот дизайнер сайта

63
00:05:16,270 --> 00:05:22,510
может фактически размещать ресурсы на разных сайтах, возможно, на разных доменах,

64
00:05:22,510 --> 00:05:27,128
и все равно иметь возможность вытаскивать данные,

65
00:05:27,128 --> 00:05:32,120
чтобы построить веб-страницу или запустить веб-приложение или запустить гибридное мобильное приложение .

66
00:05:32,120 --> 00:05:38,914
Таким образом, чтобы учесть эти ситуации,

67
00:05:38,914 --> 00:05:44,798
обработка запросов с перекрестным происхождением является метод, который позволяет нам получить доступ к этим ресурсам.

68
00:05:44,798 --> 00:05:50,410
Поэтому мы рассматриваем запрос как

69
00:05:50,410 --> 00:05:56,290
запрос с перекрестным происхождением, если вы пытаетесь получить доступ к ресурсу из другого домена

70
00:05:56,290 --> 00:06:01,240
или с другим номером порта, или с другим протоколом.

71
00:06:01,240 --> 00:06:06,920
Итак, как мы можем учитывать ситуации, когда это законный доступ к ресурсу,

72
00:06:06,920 --> 00:06:08,800
но из-за политики того же происхождения

73
00:06:08,800 --> 00:06:12,930
ваш браузер откажется загружать этот ресурс?

74
00:06:12,930 --> 00:06:15,790
Теперь, как я уже упоминал,

75
00:06:15,790 --> 00:06:20,220
многие браузеры будут ограничивать HTTP-запросы с перекрестным происхождением,

76
00:06:20,220 --> 00:06:26,420
особенно те, которые инициируются

77
00:06:26,420 --> 00:06:30,570
XMLHttpRequest или протоколом Fetch для извлечения данных.

78
00:06:30,570 --> 00:06:36,980
Они актуальны, когда мы обращаемся к ним из нашего кода JavaScript.

79
00:06:36,980 --> 00:06:41,950
Таким образом, в таких обстоятельствах имеет смысл навязывать политику одного происхождения,

80
00:06:41,950 --> 00:06:46,490
но тогда мы должны иметь способ обойти ситуацию, когда

81
00:06:46,490 --> 00:06:49,980
может быть выдан законный запрос.

82
00:06:49,980 --> 00:06:52,184
Именно здесь нам на

83
00:06:52,184 --> 00:06:56,960
помощь приходит подход CORS, основанный на совместном использовании ресурсов из разных источников.

84
00:06:56,960 --> 00:07:02,021
Таким образом, этот CORS является механизмом, который позволяет веб-серверам выполнять

85
00:07:02,021 --> 00:07:06,741
междоменные запросы или запросы перекрестного происхождения.

86
00:07:06,741 --> 00:07:10,400
Поэтому здесь браузер и сервер,

87
00:07:10,400 --> 00:07:14,375
откуда вы пытаетесь исправить ресурс, будут взаимодействовать друг с другом, а

88
00:07:14,375 --> 00:07:20,945
затем прийти к соглашению, заявив, что этот доступ является приемлемым и разрешенным.

89
00:07:20,945 --> 00:07:23,575
Таким образом, как только соглашение будет достигнуто,

90
00:07:23,575 --> 00:07:29,182
то этот запрос может быть разрешен вашим браузером.

91
00:07:29,182 --> 00:07:32,912
Таким образом, браузер и сервер будут взаимодействовать друг с другом, чтобы

92
00:07:32,912 --> 00:07:38,252
определить, является ли этот доступ к этому ресурсу приемлемой ситуацией.

93
00:07:38,252 --> 00:07:43,672
Таким образом, здесь новый набор HTTP-заголовков был

94
00:07:43,672 --> 00:07:49,010
введен в сообщения ответа HTTP, поступающие со стороны сервера.

95
00:07:49,010 --> 00:07:54,580
Эти заголовки позволяют серверам описывать набор источников

96
00:07:54,580 --> 00:08:01,690
, разрешенных сервером для доступа браузера.

97
00:08:01,690 --> 00:08:06,760
И, в свою очередь, браузер понимает, что доступ к ресурсам

98
00:08:06,760 --> 00:08:11,405
допустим, даже если они нарушают эту

99
00:08:11,405 --> 00:08:16,230
политику того же происхождения, которую мы видели ранее.

100
00:08:16,230 --> 00:08:19,876
Таким образом, в этом случае у нас есть заголовки, такие как, например,

101
00:08:19,876 --> 00:08:24,821
Access-Control-Allow-Origin,

102
00:08:24,821 --> 00:08:29,780
Access-Control-Allow-Credentials, Access-Control-Allow-Headers, Access-Control-Allow-Methods и

103
00:08:29,780 --> 00:08:35,330
несколько других, которые сервер использует для информирования браузера, говоря, что

104
00:08:35,330 --> 00:08:41,190
это приемлемый способ доступа ресурс со стороны браузера.

105
00:08:41,190 --> 00:08:46,970
И когда браузер видит эти входящие ответные сообщения со стороны сервера,

106
00:08:46,970 --> 00:08:52,510
браузер принимает и позволяет выполнить этот запрос перекрестного происхождения.

107
00:08:52,510 --> 00:08:56,500
Теперь это также означает, что сервер должен быть настроен, чтобы иметь возможность

108
00:08:56,500 --> 00:09:01,230
отвечать с этими полями заголовка и

109
00:09:01,230 --> 00:09:06,800
информацией заголовка, включенной в ответное сообщение, поступающее со стороны сервера.

110
00:09:06,800 --> 00:09:11,424
Теперь, здесь мы делим все запросы перекрестного происхождения на

111
00:09:11,424 --> 00:09:13,260
несколько категорий.

112
00:09:13,260 --> 00:09:18,495
У нас есть первый простой межсайтовый запрос.

113
00:09:18,495 --> 00:09:22,780
В простых межсайтовых запросах вы можете использовать GET или

114
00:09:22,780 --> 00:09:25,410
POST с телом запроса.

115
00:09:25,410 --> 00:09:30,180
Но когда вы используете POST, ваше тело запроса должно содержать

116
00:09:30,180 --> 00:09:34,688
либо application/x-WWW-Urlencoded,

117
00:09:34,688 --> 00:09:39,305
либо multipart/form-data, либо text/plain.

118
00:09:39,305 --> 00:09:44,805
Затем он рассматривается как простой межсайтовый запрос, и

119
00:09:44,805 --> 00:09:47,625
в этом случае пользовательские заголовки не будут разрешены.

120
00:09:47,625 --> 00:09:52,955
Таким образом, в этом случае сервер может сообщить клиенту,

121
00:09:52,955 --> 00:09:57,520
заявив, что это разрешено, и браузер должен разрешить такие запросы.

122
00:09:57,520 --> 00:10:01,700
Так, например, для широко доступных ресурсов, например,

123
00:10:01,700 --> 00:10:05,830
если вы выполняете запрос GET на сервер, чтобы получить данные для

124
00:10:05,830 --> 00:10:10,580
создания пользовательского интерфейса, тогда, возможно, запрос GET является приемлемым

125
00:10:10,580 --> 00:10:14,400
независимо от того, из какого источника исходит этот запрос.

126
00:10:14,400 --> 00:10:17,350
Таким образом, в этом случае ваш сервер ответит клиенту,

127
00:10:17,350 --> 00:10:23,250
сказав Access-Conrol-Allow-Origin, с этой звездочкой подстановок здесь,

128
00:10:23,250 --> 00:10:27,830
что означает, что любое происхождение, которое создает запрос, приемлемо, и

129
00:10:27,830 --> 00:10:33,540
браузер должен разрешить выполнение запроса на этот сервер.

130
00:10:33,540 --> 00:10:38,020
И теперь вы также можете ограничить доступ к источнику.

131
00:10:38,020 --> 00:10:44,440
В этом случае можно конкретно сказать, что если источником является

132
00:10:44,440 --> 00:10:50,090
конкретный сайт, то приемлемо обслуживать этот запрос.

133
00:10:50,090 --> 00:10:55,940
Таким образом, браузер видит, что отправка запросов

134
00:10:55,940 --> 00:11:01,230
с этим конкретным исходным сайтом в запросе приемлема, и

135
00:11:01,230 --> 00:11:03,830
мы разрешим запрос перекрестного происхождения.

136
00:11:03,830 --> 00:11:08,790
Таким образом, вы можете контролировать способ происхождения

137
00:11:08,790 --> 00:11:12,870
указан в сообщении запроса, поступающем со стороны клиента.

138
00:11:12,870 --> 00:11:17,500
Таким образом, сервер может принимать такие запросы.

139
00:11:17,500 --> 00:11:23,094
Некоторые другие запросы будут подпадать под категорию предварительных запросов.

140
00:11:23,094 --> 00:11:27,750
В предполетном запросе вы ожидаете, что перед отправкой клиентом

141
00:11:27,750 --> 00:11:32,380
фактического запроса клиент отправит предпечатный запрос,

142
00:11:32,380 --> 00:11:37,260
что означает, что он связывается с сервером для получения

143
00:11:37,260 --> 00:11:41,380
информации от сервера до того, как будет выдан фактический запрос.

144
00:11:41,380 --> 00:11:46,580
Это особенно случай, когда вы выдаете запросы PUT и DELETE,

145
00:11:46,580 --> 00:11:52,160
потому что запросы PUT и DELETE могут вызвать изменения на стороне сервера.

146
00:11:52,160 --> 00:11:58,100
И поэтому любой метод, который вызывает побочные эффекты на данных сервера, например

147
00:11:58,100 --> 00:12:03,538
запрос PUT и DELETE, специально уполномочен следовать предполетному подходу.

148
00:12:03,538 --> 00:12:08,276
В предпечатном подходе идея заключается в том, что клиент

149
00:12:08,276 --> 00:12:12,919
сначала отправит запрос HTTP OPTIONS на стороне сервера, и

150
00:12:12,919 --> 00:12:19,174
в ответ на это сообщение запроса OPTIONS со стороны клиента, сервер будет

151
00:12:19,174 --> 00:12:24,864
отвечать соответствующим Access-Control-Allow-Headers,

152
00:12:24,864 --> 00:12:31,504
Access-Control-Allow-Origin, и

153
00:12:31,504 --> 00:12:36,350
информация заголовка Access-Control-Allow-Credentials в ответе на сообщение OPTIONS.

154
00:12:36,350 --> 00:12:42,359
После этого клиент решит, может ли он выдать запрос перекрестного происхождения или

155
00:12:42,359 --> 00:12:48,870
нет, основываясь на ответе на предпечатный запрос OPTIONS, отправленный клиентом.

156
00:12:48,870 --> 00:12:53,410
Таким образом, здесь вам нужно пройти два шага, прежде чем ваш запрос

157
00:12:53,410 --> 00:12:57,205
может быть разрешен и обслужин на стороне сервера.

158
00:12:58,340 --> 00:13:03,230
Третьей категорией запросов CORS будет то, что называется проверенными запросами,

159
00:13:03,230 --> 00:13:07,900
где вы ожидаете, что клиент будет включать учетные данные в заголовок

160
00:13:07,900 --> 00:13:09,608
сообщения запроса.

161
00:13:09,608 --> 00:13:13,518
Таким образом, запросы, которые сопровождаются куки, например, для

162
00:13:13,518 --> 00:13:19,040
распознавания сеанса на стороне сервера, или какая-то HTTP-аутентификация

163
00:13:19,040 --> 00:13:24,440
информации в заголовке авторизации в сообщении запроса.

164
00:13:24,440 --> 00:13:27,843
Таким образом, в этом случае сервер должен ответить с помощью

165
00:13:27,843 --> 00:13:32,460
Access-Control-Allow-Credentials: true на стороне клиента.

166
00:13:32,460 --> 00:13:37,920
Таким образом, в этом случае сервер ответит этим, а

167
00:13:37,920 --> 00:13:41,070
затем клиенту будет разрешено отправлять

168
00:13:41,070 --> 00:13:45,720
информацию о своих учетных данных во входящем запросе со стороны клиента.

169
00:13:45,720 --> 00:13:50,430
Теперь, в этом случае, Access-Control-Allow-Origin не разрешается

170
00:13:50,430 --> 00:13:56,550
иметь в ответном сообщении символ-символ.

171
00:13:56,550 --> 00:14:00,770
Ожидается, что явное указание источника, к

172
00:14:00,770 --> 00:14:03,450
которому может быть инициирован запрос.

173
00:14:04,500 --> 00:14:08,235
Теперь, очевидно, мы можем реализовать большую часть работы,

174
00:14:08,235 --> 00:14:13,796
что нам нужно сделать на стороне сервера, реализуя наше собственное промежуточное программное обеспечение, если мы так

175
00:14:13,796 --> 00:14:19,260
решили обрабатывать ответы, связанные с CORS со стороны сервера.

176
00:14:19,260 --> 00:14:23,570
Это очень просто, как мы видели в коде, который мы реализовали.

177
00:14:23,570 --> 00:14:29,140
Конечно, это один из способов обработки ответов, связанных с CORS со стороны сервера,

178
00:14:29,140 --> 00:14:34,800
но, к счастью, у нас есть конкретный CORS NodemoDule,

179
00:14:34,800 --> 00:14:40,470
который предназначен для обработки этой самой

180
00:14:40,470 --> 00:14:44,920
работы, которую сервер должен выполнить для удовлетворения требований CORS.

181
00:14:44,920 --> 00:14:50,790
Таким образом, CORS NodemoDule позволяет нам настроить CORS на стороне сервера, в

182
00:14:50,790 --> 00:14:55,810
том числе указать информацию о происхождении, где будут приняты учетные данные,

183
00:14:55,810 --> 00:15:01,010
и многие другие сведения, так что вы можете настроить сервер,

184
00:15:01,010 --> 00:15:05,630
чтобы иметь возможность обрабатывать ответы, связанные с CORS, которые он должен дать

185
00:15:05,630 --> 00:15:09,480
в браузер в ответ на сообщение запроса.

186
00:15:09,480 --> 00:15:15,750
Чтобы установить CORS NodemoDule, очевидно, вы видите npm install cors,

187
00:15:15,750 --> 00:15:22,280
а затем настроить промежуточное программное обеспечение CORS в вашем экспресс-приложении.

188
00:15:23,430 --> 00:15:28,940
Сам модуль CORS обеспечивает очень простой способ включения CORS.

189
00:15:28,940 --> 00:15:35,970
Вы можете просто включить использование приложения CORS с пустыми скобками, и

190
00:15:35,970 --> 00:15:41,370
это по существу означает, что вы открываете свой сервер, и он будет отвечать с помощью

191
00:15:41,370 --> 00:15:47,180
Access-Control-Allow-Origin со звездой Wild карты на каждый входящий запрос.

192
00:15:47,180 --> 00:15:51,940
Но когда вы настраиваете свой сервер, вы можете захотеть больше контроля над этим, так

193
00:15:51,940 --> 00:15:57,190
что здесь мы можем указать дополнительные параметры для CORS.

194
00:15:57,190 --> 00:16:02,790
И не только это, вы можете навязать обработку CORS

195
00:16:02,790 --> 00:16:06,810
по-разному для разных маршрутов на стороне вашего сервера.

196
00:16:06,810 --> 00:16:12,320
Таким образом, как мы увидим в упражнении, мы будем накладывать различные требования CORS

197
00:16:12,320 --> 00:16:17,540
на разных маршрутах на нашей стороне сервера, и все это настраивается с помощью

198
00:16:17,540 --> 00:16:22,690
различных параметров конфигурации, которые CORS NodemoDule поддерживает для нас.

199
00:16:22,690 --> 00:16:28,620
Таким образом, используя CORS NodemoDule, очень легко настроить ваш сервер для обработки

200
00:16:28,620 --> 00:16:34,020
любых запросов перекрестного происхождения, поступающих с вашей клиентской стороны, а

201
00:16:34,020 --> 00:16:39,730
затем отвечать с соответствующей информацией заголовка на стороне клиента

202
00:16:39,730 --> 00:16:45,310
с соответствующими заголовками CORS в ответном сообщении со стороны сервера.

203
00:16:45,310 --> 00:16:48,450
С этим быстрым пониманием CORS,

204
00:16:48,450 --> 00:16:54,730
я уверен, что у вас на данный момент больше вопросов, чем ответов из этой лекции.

205
00:16:54,730 --> 00:16:58,960
Но если вы хотите прочитать гораздо больше информации о CORS,

206
00:16:58,960 --> 00:17:04,050
я предоставил вам дополнительные ресурсы в конце этого урока,

207
00:17:04,050 --> 00:17:06,804
которые позволят вам узнать больше о самой CORS.

208
00:17:06,804 --> 00:17:11,553
Но с точки зрения этого курса, мы хотели бы настроить наше

209
00:17:11,553 --> 00:17:15,037
экспресс-приложение, которое мы разрабатываем

210
00:17:15,037 --> 00:17:19,150
до сих пор для обработки вопросов, связанных с CORS на стороне сервера.

211
00:17:19,150 --> 00:17:24,941
Таким образом, перейдя к упражнению, мы установим модуль CORS npm, а

212
00:17:24,941 --> 00:17:30,236
затем настроим его на различных маршрутах внутри нашего дополнительного сервера.

213
00:17:30,236 --> 00:17:33,629
[ МУЗЫКА]