1
00:00:00,000 --> 00:00:04,746
[MÚSICA]

2
00:00:04,746 --> 00:00:08,050
Vamos falar em alguma linguagem CORS agora.

3
00:00:08,050 --> 00:00:11,500
Agora, o que exatamente é compartilhamento de resultados de origem cruzada, e

4
00:00:11,500 --> 00:00:15,325
por que é relevante quando olhamos para aplicativos web e

5
00:00:15,325 --> 00:00:21,010
aplicativos hipermóveis como temos feito nesta especialização?

6
00:00:21,010 --> 00:00:25,260
Como você entende, a maioria das páginas da Web agora obtém dados de

7
00:00:25,260 --> 00:00:29,790
muitos sites diferentes, a fim de construir uma página da Web.

8
00:00:29,790 --> 00:00:38,470
Agora, a fim de impor uma política rigorosa de acesso a recursos de diferentes sites,

9
00:00:38,470 --> 00:00:44,220
a mesma política de origem tem sido imposta por muitos navegadores.

10
00:00:44,220 --> 00:00:49,410
Vamos falar um pouco sobre isso com mais detalhes nos próximos slides, mas

11
00:00:49,410 --> 00:00:55,950
no contexto dos frameworks que temos discutido nesta

12
00:00:55,950 --> 00:01:00,640
especialização em particular, como Angular, Ionic e NativeScript,

13
00:01:00,640 --> 00:01:05,650
muitos deles envolverão scripts, código JavaScript,

14
00:01:05,650 --> 00:01:11,220
que podem ter que acessar recursos de diferentes sites.

15
00:01:11,220 --> 00:01:16,790
E é aqui que o problema CORS surge muito facilmente.

16
00:01:16,790 --> 00:01:22,290
Vamos ver como vamos abordar esta questão com mais detalhes nesta palestra e

17
00:01:22,290 --> 00:01:24,050
no exercício que se segue.

18
00:01:25,940 --> 00:01:31,446
Eu brevemente aludi à política de mesma origem que comecei esta palestra.

19
00:01:31,446 --> 00:01:36,510
Agora, a política de mesma origem é um modelo de segurança de aplicativo da Web

20
00:01:36,510 --> 00:01:40,170
que restringe como um documento ou um script

21
00:01:40,170 --> 00:01:45,380
carregado de uma origem interagem com recursos de outra origem.

22
00:01:45,380 --> 00:01:50,270
O objetivo disso é isolar documentos potencialmente mal-intencionados.

23
00:01:50,270 --> 00:01:54,940
Agora, obviamente, quando você tem uma página da Web que envolve script,

24
00:01:54,940 --> 00:02:00,900
código JavaScript, que pode acessar recursos de outro local,

25
00:02:00,900 --> 00:02:05,185
código potencialmente malicioso pode ser injetado em sua página da Web e

26
00:02:05,185 --> 00:02:12,800
pelo qual acessar uma origem diferente de onde sua página da Web é obtida.

27
00:02:12,800 --> 00:02:17,220
Agora, essa é a razão pela qual muitos navegadores impõem essa política de mesma origem.

28
00:02:17,220 --> 00:02:22,230
Agora, quando falamos sobre a mesma origem, como especificamos uma origem?

29
00:02:22,230 --> 00:02:28,540
Agora, neste contexto, uma origem para qualquer recurso é definida por três tuplas.

30
00:02:28,540 --> 00:02:32,980
Primeiro, o protocolo que é usado para acessar o recurso.

31
00:02:32,980 --> 00:02:39,410
Em segundo lugar, o nome do host do recurso ou o domínio desse recurso.

32
00:02:39,410 --> 00:02:43,480
E em terceiro lugar, o número da porta na qual esse recurso está sendo acessado.

33
00:02:43,480 --> 00:02:48,700
Então é assim que identificamos a origem de qualquer recurso. O

34
00:02:48,700 --> 00:02:53,626
recurso neste caso pode ser uma página html, uma imagem,

35
00:02:53,626 --> 00:03:00,720
dados JSON obtidos a partir de um ponto final da API REST e muito mais.

36
00:03:00,720 --> 00:03:05,410
Para aprofundar a política de mesma origem, vejamos um exemplo.

37
00:03:05,410 --> 00:03:12,315
Suponha que temos uma página da Web que é carregada a partir deste site listado aqui,

38
00:03:12,315 --> 00:03:17,330
www.abc.com, e em uma pasta xyz, e

39
00:03:17,330 --> 00:03:21,210
o page.html sendo carregado aqui.

40
00:03:21,210 --> 00:03:26,890
Esta página pode envolver links ou até mesmo código JavaScript que pode

41
00:03:26,890 --> 00:03:33,200
emitir XMLHttpRequest para outros recursos na página da Web.

42
00:03:33,200 --> 00:03:38,310
Agora, neste caso, se tentarmos acessar outro URL, por

43
00:03:38,310 --> 00:03:42,690
exemplo, o primeiro listado aqui, que obviamente você vê é

44
00:03:42,690 --> 00:03:47,860
do mesmo site, mas de uma pasta diferente.

45
00:03:47,860 --> 00:03:51,820
Isso é aceitável, porque a origem, neste caso,

46
00:03:51,820 --> 00:03:55,420
o protocolo que está sendo usado e o número da porta, permanece a mesma.

47
00:03:55,420 --> 00:04:00,660
Então, isso é aceitável para acessar esse recurso.

48
00:04:00,660 --> 00:04:05,470
Da mesma forma, no segundo caso, podemos ter sob

49
00:04:07,040 --> 00:04:10,570
vários níveis de subpastas um recurso que está sendo acessado.

50
00:04:10,570 --> 00:04:15,850
Mas, novamente, uma vez que sua origem permanece a mesma, o que é aceitável.

51
00:04:15,850 --> 00:04:18,260
Mas vejamos o terceiro exemplo aqui.

52
00:04:18,260 --> 00:04:23,930
Neste exemplo, vemos que estamos tentando acessar um recurso aqui com

53
00:04:23,930 --> 00:04:31,230
o protocolo https, que obviamente viola o principal de mesma origem

54
00:04:31,230 --> 00:04:35,580
porque estamos usando um protocolo diferente para acessar esse recurso neste momento.

55
00:04:35,580 --> 00:04:39,030
Então, isso seria considerado um fracasso neste caso.

56
00:04:39,030 --> 00:04:44,840
O quarto caso é onde estamos acessando um recurso com um número de porta diferente.

57
00:04:44,840 --> 00:04:50,300
E o quinto caso é onde estamos acessando um recurso em um host diferente.

58
00:04:50,300 --> 00:04:54,830
Agora, todos esses três seriam marcados como não válidos ou não

59
00:04:54,830 --> 00:04:58,110
podem ser acessados sob essa política de mesma origem.

60
00:04:58,110 --> 00:05:02,710
Então, se você impor a política de mesma origem para acesso a partir, por exemplo, do

61
00:05:02,710 --> 00:05:10,970
seu XMLHttpRequest, então os três últimos não serão permitidos neste caso.

62
00:05:10,970 --> 00:05:16,270
Mas, é claro, há muitas situações em que esse designer de site

63
00:05:16,270 --> 00:05:22,510
pode realmente hospedar recursos em sites diferentes, talvez em domínios diferentes,

64
00:05:22,510 --> 00:05:27,128
e ainda ser capaz de extrair os dados para construir a página da Web ou

65
00:05:27,128 --> 00:05:32,120
para fazer o aplicativo web executar ou para fazer o aplicativo móvel híbrido executar .

66
00:05:32,120 --> 00:05:38,914
Então, para acomodar essas situações, o

67
00:05:38,914 --> 00:05:44,798
tratamento de solicitações de origem cruzada é um método que nos permite acessar esses recursos.

68
00:05:44,798 --> 00:05:50,410
Portanto, consideramos uma solicitação para ser uma

69
00:05:50,410 --> 00:05:56,290
solicitação de origem cruzada se você estiver tentando acessar um recurso de um domínio diferente,

70
00:05:56,290 --> 00:06:01,240
ou em um número de porta diferente, ou com um protocolo diferente.

71
00:06:01,240 --> 00:06:06,920
Então, como podemos acomodar situações em que este é um acesso legítimo a um recurso,

72
00:06:06,920 --> 00:06:08,800
mas devido à política de mesma origem,

73
00:06:08,800 --> 00:06:12,930
seu navegador se recusará a carregar esse recurso?

74
00:06:12,930 --> 00:06:15,790
Agora é aqui que, como mencionei,

75
00:06:15,790 --> 00:06:20,220
muitos navegadores restringirão solicitações http de origem cruzada,

76
00:06:20,220 --> 00:06:26,420
especialmente aquelas que são iniciadas por XMLHttpRequest ou

77
00:06:26,420 --> 00:06:30,570
pelo protocolo Fetch para buscar dados.

78
00:06:30,570 --> 00:06:36,980
Estes são relevantes quando os acessamos a partir de nosso código JavaScript.

79
00:06:36,980 --> 00:06:41,950
Por conseguinte, nestas circunstâncias, faz sentido impor a política de mesma origem,

80
00:06:41,950 --> 00:06:46,490
mas então deveríamos ter uma forma de contornar a situação em que

81
00:06:46,490 --> 00:06:49,980
um pedido legítimo pode ser emitido.

82
00:06:49,980 --> 00:06:52,184
É aqui que a abordagem CORS,

83
00:06:52,184 --> 00:06:56,960
a abordagem de partilha de recursos de origem cruzada, vem em nosso auxílio.

84
00:06:56,960 --> 00:07:02,021
Portanto, este CORS é um mecanismo que permite que os servidores Web executem

85
00:07:02,021 --> 00:07:06,741
solicitações entre domínios ou solicitações de origem cruzada.

86
00:07:06,741 --> 00:07:10,400
Então aqui o navegador e o servidor

87
00:07:10,400 --> 00:07:14,375
de onde você está tentando corrigir o recurso irão interagir uns com os outros e

88
00:07:14,375 --> 00:07:20,945
, em seguida, chegar a um acordo dizendo que esse acesso é aceitável e permitido.

89
00:07:20,945 --> 00:07:23,575
Assim, uma vez que o acordo é alcançado,

90
00:07:23,575 --> 00:07:29,182
então este pedido pode ser permitido pelo seu navegador.

91
00:07:29,182 --> 00:07:32,912
Assim, o navegador e o servidor irão interagir uns com os outros, a fim de

92
00:07:32,912 --> 00:07:38,252
determinar se este acesso a este recurso é uma situação aceitável.

93
00:07:38,252 --> 00:07:43,672
Então é aqui que um novo conjunto de cabeçalhos HTTP foram

94
00:07:43,672 --> 00:07:49,010
introduzidos nas mensagens de resposta HTTP provenientes do lado do servidor.

95
00:07:49,010 --> 00:07:54,580
Esses cabeçalhos permitem que os servidores descrevam o conjunto de origens

96
00:07:54,580 --> 00:08:01,690
que são permitidas pelo servidor para ser acessado pelo navegador.

97
00:08:01,690 --> 00:08:06,760
E, por sua vez, o navegador percebe que esses acessos de recursos

98
00:08:06,760 --> 00:08:11,405
são aceitáveis para serem permitidos, mesmo que eles estejam violando a

99
00:08:11,405 --> 00:08:16,230
política de mesma origem que vimos anteriormente.

100
00:08:16,230 --> 00:08:19,876
Então, neste caso, temos cabeçalhos como, por exemplo,

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

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

103
00:08:29,780 --> 00:08:35,330
alguns outros que o servidor usa para informar o navegador, dizendo que

104
00:08:35,330 --> 00:08:41,190
esta é uma maneira aceitável de acessar o recurso do lado do navegador.

105
00:08:41,190 --> 00:08:46,970
E quando o navegador vê essas mensagens de resposta recebidas do lado do servidor,

106
00:08:46,970 --> 00:08:52,510
o navegador aceita e permite que essa solicitação de origem cruzada seja executada.

107
00:08:52,510 --> 00:08:56,500
Agora, isso também significa que o servidor deve ser configurado para ser capaz de

108
00:08:56,500 --> 00:09:01,230
responder com esses campos de cabeçalho e

109
00:09:01,230 --> 00:09:06,800
as informações de cabeçalho incluídas na mensagem de resposta vinda do lado do servidor.

110
00:09:06,800 --> 00:09:11,424
Agora, é aqui que dividimos todas as solicitações de origem cruzada em

111
00:09:11,424 --> 00:09:13,260
várias categorias.

112
00:09:13,260 --> 00:09:18,495
Temos o primeiro a ser o simples pedido cross-site.

113
00:09:18,495 --> 00:09:22,780
Em solicitações simples entre sites, você pode estar usando o GET ou

114
00:09:22,780 --> 00:09:25,410
o POST com o corpo da solicitação.

115
00:09:25,410 --> 00:09:30,180
Mas quando você estiver usando o POST, seu corpo de solicitação deve conter

116
00:09:30,180 --> 00:09:34,688
application/X-www-urlencoded,

117
00:09:34,688 --> 00:09:39,305
ou multipart/form-data, ou text/plain.

118
00:09:39,305 --> 00:09:44,805
Em seguida, ele é tratado como uma simples solicitação entre sites e

119
00:09:44,805 --> 00:09:47,625
nenhum cabeçalho personalizado será permitido neste caso.

120
00:09:47,625 --> 00:09:52,955
Assim, neste caso, é aceitável que o servidor informe o cliente,

121
00:09:52,955 --> 00:09:57,520
dizendo que isso é permitido e o navegador deve permitir tais solicitações.

122
00:09:57,520 --> 00:10:01,700
Então, por exemplo, para recursos amplamente acessados, como, por exemplo,

123
00:10:01,700 --> 00:10:05,830
se você executar uma solicitação GET para um servidor a fim de buscar os dados a fim de

124
00:10:05,830 --> 00:10:10,580
construir a interface do usuário, então talvez a solicitação GET seja aceitável

125
00:10:10,580 --> 00:10:14,400
independentemente da origem da solicitação.

126
00:10:14,400 --> 00:10:17,350
Então, nesse caso, seu servidor responderá ao cliente,

127
00:10:17,350 --> 00:10:23,250
dizendo Access-Conrol-Allow-Origin, com essa estrela curinga aqui, o

128
00:10:23,250 --> 00:10:27,830
que significa que qualquer origem que origine a solicitação é aceitável, e

129
00:10:27,830 --> 00:10:33,540
o navegador deve permitir que a solicitação seja executada para esse servidor.

130
00:10:33,540 --> 00:10:38,020
E agora, você também pode restringir o acesso à origem.

131
00:10:38,020 --> 00:10:44,440
Neste caso, você pode dizer especificamente que, se a origem for

132
00:10:44,440 --> 00:10:50,090
um site específico, é aceitável atender esta solicitação.

133
00:10:50,090 --> 00:10:55,940
Assim, o navegador vê que o envio de solicitações

134
00:10:55,940 --> 00:11:01,230
com este site de origem específico na solicitação é aceitável e

135
00:11:01,230 --> 00:11:03,830
vamos permitir a solicitação de origem cruzada.

136
00:11:03,830 --> 00:11:08,790
Assim, você pode controlar a forma como a origem é

137
00:11:08,790 --> 00:11:12,870
especificada na mensagem de solicitação vinda do lado do cliente.

138
00:11:12,870 --> 00:11:17,500
Assim, o servidor é capaz de aceitar tais solicitações.

139
00:11:17,500 --> 00:11:23,094
Alguns outros pedidos estariam sob a categoria de pedidos predefinidos.

140
00:11:23,094 --> 00:11:27,750
Na solicitação preflit, você espera que antes que o cliente envie

141
00:11:27,750 --> 00:11:32,380
a solicitação real, o cliente enviará uma solicitação de comprovação, o

142
00:11:32,380 --> 00:11:37,260
que significa que ele contata o servidor para obter

143
00:11:37,260 --> 00:11:41,380
informações do servidor antes que a solicitação real seja emitida.

144
00:11:41,380 --> 00:11:46,580
Este é especificamente o caso em que você emite solicitações PUT e DELETE

145
00:11:46,580 --> 00:11:52,160
porque as solicitações PUT e DELETE podem causar alterações no lado do servidor.

146
00:11:52,160 --> 00:11:58,100
Assim, qualquer método que cause efeitos colaterais nos dados do servidor, como o PUT e

147
00:11:58,100 --> 00:12:03,538
a solicitação DELETE, são especialmente mandatados para seguir a abordagem de comprovação.

148
00:12:03,538 --> 00:12:08,276
Na abordagem de comprovação, a idéia é que o cliente irá

149
00:12:08,276 --> 00:12:12,919
primeiro enviar uma solicitação HTTP OPTIONS para o lado do servidor, e

150
00:12:12,919 --> 00:12:19,174
em resposta a essa mensagem de solicitação OPTIONS do lado do cliente, o servidor

151
00:12:19,174 --> 00:12:24,864
responderá com o Access-Control-Allow-Headers correspondentes,

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

153
00:12:31,504 --> 00:12:36,350
informações de cabeçalho Access-Control-Allow-Credentials na resposta a uma mensagem OPTIONS.

154
00:12:36,350 --> 00:12:42,359
Posteriormente, o cliente decidirá se pode emitir a solicitação de origem cruzada ou

155
00:12:42,359 --> 00:12:48,870
não com base na resposta à solicitação de comprovação OPTIONS que o cliente enviou.

156
00:12:48,870 --> 00:12:53,410
Então é aqui que você tem que passar por duas etapas antes que sua solicitação

157
00:12:53,410 --> 00:12:57,205
possa ser permitida e atendida pelo lado do servidor.

158
00:12:58,340 --> 00:13:03,230
Uma terceira categoria de solicitações CORS seria o que são chamados de solicitações credenciadas,

159
00:13:03,230 --> 00:13:07,900
onde você espera que o cliente inclua credenciais no cabeçalho

160
00:13:07,900 --> 00:13:09,608
da mensagem de solicitação.

161
00:13:09,608 --> 00:13:13,518
Assim, as solicitações que são acompanhadas por cookies, por exemplo, para

162
00:13:13,518 --> 00:13:19,040
reconhecer a sessão no lado do servidor, ou algum tipo de

163
00:13:19,040 --> 00:13:24,440
informações de autenticação HTTP no cabeçalho de autorização na mensagem de solicitação.

164
00:13:24,440 --> 00:13:27,843
Então, neste caso, o servidor precisa responder com

165
00:13:27,843 --> 00:13:32,460
Access-Control-Allow-Credentials: fiel ao lado do cliente.

166
00:13:32,460 --> 00:13:37,920
Então, neste caso, o servidor responderá com isso e,

167
00:13:37,920 --> 00:13:41,070
em seguida, o cliente terá permissão para enviar suas

168
00:13:41,070 --> 00:13:45,720
informações de credenciais na solicitação de entrada do lado do cliente.

169
00:13:45,720 --> 00:13:50,430
Agora, neste caso, o Access-Control-Allow-Origin não tem permissão

170
00:13:50,430 --> 00:13:56,550
para ter o curinga, a estrela, na mensagem de resposta.

171
00:13:56,550 --> 00:14:00,770
Espera-se especificar explicitamente a origem para a

172
00:14:00,770 --> 00:14:03,450
qual a solicitação pode ser iniciada.

173
00:14:04,500 --> 00:14:08,235
Agora, obviamente, podemos implementar grande parte do trabalho,

174
00:14:08,235 --> 00:14:13,796
o que precisamos fazer no lado do servidor, implementando nosso próprio middleware se assim

175
00:14:13,796 --> 00:14:19,260
optarmos por lidar com as respostas relacionadas ao CORS do lado do servidor.

176
00:14:19,260 --> 00:14:23,570
É muito simples, como vimos no código que implementamos.

177
00:14:23,570 --> 00:14:29,140
Claro, essa é uma maneira de lidar com respostas relacionadas ao CORS do lado do servidor,

178
00:14:29,140 --> 00:14:34,800
mas felizmente, temos um CORS NodeModule específico

179
00:14:34,800 --> 00:14:40,470
que é projetado para lidar com esse tipo de

180
00:14:40,470 --> 00:14:44,920
trabalho que o servidor precisa fazer para atender aos requisitos CORS.

181
00:14:44,920 --> 00:14:50,790
Assim, o CORS NodeModule nos permite configurar o CORS no lado do servidor,

182
00:14:50,790 --> 00:14:55,810
incluindo especificar informações de origem onde as credenciais seriam aceitas

183
00:14:55,810 --> 00:15:01,010
e muitas outras informações, de modo que você pode configurar o servidor

184
00:15:01,010 --> 00:15:05,630
para ser capaz de lidar com respostas relacionadas a CORS que ele precisa fornecer para

185
00:15:05,630 --> 00:15:09,480
o navegador em resposta à mensagem de solicitação.

186
00:15:09,480 --> 00:15:15,750
Para instalar o CORS NodeModule, obviamente você vê npm install cors

187
00:15:15,750 --> 00:15:22,280
e, em seguida, configurar o middleware CORS dentro de sua aplicação express.

188
00:15:23,430 --> 00:15:28,940
O módulo CORS em si fornece uma maneira muito simples de ativar o CORS.

189
00:15:28,940 --> 00:15:35,970
Você pode simplesmente incluir o uso do aplicativo CORS com colchetes vazios, e

190
00:15:35,970 --> 00:15:41,370
isso significa essencialmente que você está abrindo seu servidor, e ele responderá com

191
00:15:41,370 --> 00:15:47,180
o Access-Control-Allow-Origin com a estrela curinga para cada solicitação recebida.

192
00:15:47,180 --> 00:15:51,940
Mas quando você está configurando seu servidor, você pode querer mais controle sobre isso, de modo

193
00:15:51,940 --> 00:15:57,190
que é onde podemos especificar opções adicionais para o CORS.

194
00:15:57,190 --> 00:16:02,790
E não só isso, você pode impor o manuseio de CORS de

195
00:16:02,790 --> 00:16:06,810
forma diferente para diferentes rotas dentro do lado do servidor.

196
00:16:06,810 --> 00:16:12,320
Então, como veremos no exercício, vamos impor diferentes requisitos CORS nas

197
00:16:12,320 --> 00:16:17,540
diferentes rotas do lado do nosso servidor, e tudo isso é configurado usando

198
00:16:17,540 --> 00:16:22,690
várias opções de configuração que o CORS NodeModule suporta para nós.

199
00:16:22,690 --> 00:16:28,620
Então, usando o CORS NodeModule, é muito fácil configurar seu servidor para lidar com

200
00:16:28,620 --> 00:16:34,020
quaisquer solicitações de origem cruzada provenientes do lado do cliente e, em

201
00:16:34,020 --> 00:16:39,730
seguida, responder com informações de cabeçalho apropriadas para o lado do cliente

202
00:16:39,730 --> 00:16:45,310
com cabeçalhos CORS apropriados na mensagem de resposta do lado do servidor.

203
00:16:45,310 --> 00:16:48,450
Com esta rápida compreensão do CORS,

204
00:16:48,450 --> 00:16:54,730
tenho certeza que você tem mais perguntas neste momento do que respostas desta palestra.

205
00:16:54,730 --> 00:16:58,960
Mas se você gostaria de ler muito mais detalhes sobre CORS,

206
00:16:58,960 --> 00:17:04,050
eu forneci recursos adicionais no final desta lição,

207
00:17:04,050 --> 00:17:06,804
que permitem que você leia mais sobre o próprio CORS.

208
00:17:06,804 --> 00:17:11,553
Mas do ponto de vista deste curso, gostaríamos de configurar nossa

209
00:17:11,553 --> 00:17:15,037
aplicação expressa que temos vindo a desenvolver

210
00:17:15,037 --> 00:17:19,150
até agora para lidar com assuntos relacionados ao CORS no lado do servidor.

211
00:17:19,150 --> 00:17:24,941
Então, passando para o exercício, vamos instalar o módulo CORS npm e, em

212
00:17:24,941 --> 00:17:30,236
seguida, configurá-lo em várias rotas dentro do nosso servidor extra.

213
00:17:30,236 --> 00:17:33,629
[ MUSIC]