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

2
00:00:04,746 --> 00:00:08,050
Hablemos en algún lenguaje CORS ahora.

3
00:00:08,050 --> 00:00:11,500
Ahora, ¿qué es exactamente compartir resultados de origen cruzado, y

4
00:00:11,500 --> 00:00:15,325
por qué es relevante cuando miramos aplicaciones web y

5
00:00:15,325 --> 00:00:21,010
aplicaciones hipermóviles como hemos estado haciendo en esta especialización?

6
00:00:21,010 --> 00:00:25,260
Como usted entiende, la mayoría de las páginas web ahora extraen datos de

7
00:00:25,260 --> 00:00:29,790
muchos sitios diferentes para construir una página web.

8
00:00:29,790 --> 00:00:38,470
Ahora, con el fin de imponer una política estricta de acceso a los recursos de diferentes sitios,

9
00:00:38,470 --> 00:00:44,220
la misma política de origen ha sido impuesta por muchos navegadores.

10
00:00:44,220 --> 00:00:49,410
Hablaremos un poco de eso con más detalle en las próximas diapositivas, pero

11
00:00:49,410 --> 00:00:55,950
en el contexto de los frameworks que hemos estado discutiendo en esta

12
00:00:55,950 --> 00:01:00,640
especialización particular, como Angular, Ionic y NativeScript,

13
00:01:00,640 --> 00:01:05,650
muchos de estos implicarán scripts, código JavaScript,

14
00:01:05,650 --> 00:01:11,220
que podría tener que acceder a recursos de diferentes sitios.

15
00:01:11,220 --> 00:01:16,790
Y aquí es donde el problema CORS surge muy fácilmente.

16
00:01:16,790 --> 00:01:22,290
Veamos cómo abordaremos este tema con más detalle en esta conferencia y

17
00:01:22,290 --> 00:01:24,050
el ejercicio que sigue.

18
00:01:25,940 --> 00:01:31,446
He aludido brevemente a la política del mismo origen que he empezado esta conferencia.

19
00:01:31,446 --> 00:01:36,510
Ahora, la política del mismo origen es un modelo de seguridad de aplicaciones web

20
00:01:36,510 --> 00:01:40,170
que restringe cómo un documento o un script

21
00:01:40,170 --> 00:01:45,380
cargado desde un origen interactuará con los recursos de otro origen.

22
00:01:45,380 --> 00:01:50,270
El propósito de esto es aislar documentos potencialmente maliciosos.

23
00:01:50,270 --> 00:01:54,940
Ahora, obviamente, cuando tiene una página web que involucra script,

24
00:01:54,940 --> 00:02:00,900
código JavaScript, que podría acceder a recursos desde otra ubicación,

25
00:02:00,900 --> 00:02:05,185
se podría inyectar código potencialmente malicioso en su página web y

26
00:02:05,185 --> 00:02:12,800
por lo que acceder a un origen diferente al de donde se obtiene su página web.

27
00:02:12,800 --> 00:02:17,220
Ahora, esa es la razón por la que muchos navegadores imponen esta política del mismo origen.

28
00:02:17,220 --> 00:02:22,230
Ahora, cuando hablamos del mismo origen, ¿cómo especificamos un origen?

29
00:02:22,230 --> 00:02:28,540
Ahora, en este contexto, un origen para cualquier recurso está definido por tres tuplas.

30
00:02:28,540 --> 00:02:32,980
Primero, el protocolo que se utiliza para acceder al recurso.

31
00:02:32,980 --> 00:02:39,410
En segundo lugar, el nombre de host del recurso o el dominio de ese recurso.

32
00:02:39,410 --> 00:02:43,480
Y en tercer lugar, el número de puerto en el que se accede a ese recurso.

33
00:02:43,480 --> 00:02:48,700
Así es como identificamos el origen de cualquier recurso. El

34
00:02:48,700 --> 00:02:53,626
recurso en este caso podría ser una página html, una imagen,

35
00:02:53,626 --> 00:03:00,720
datos JSON que se obtienen de un punto final de API REST y muchos más.

36
00:03:00,720 --> 00:03:05,410
Para más detalles sobre la política del mismo origen, veamos un ejemplo.

37
00:03:05,410 --> 00:03:12,315
Supongamos que tenemos una página web que se carga desde este sitio enumerado aquí,

38
00:03:12,315 --> 00:03:17,330
www.abc.com, y en una carpeta xyz, y

39
00:03:17,330 --> 00:03:21,210
el page.html que se está cargando aquí.

40
00:03:21,210 --> 00:03:26,890
Esta página puede incluir enlaces o incluso código JavaScript que podría

41
00:03:26,890 --> 00:03:33,200
emitir XMLHttpRequest a otros recursos de la página web.

42
00:03:33,200 --> 00:03:38,310
Ahora, en este caso, si intentamos acceder a otra URL, por

43
00:03:38,310 --> 00:03:42,690
ejemplo, la primera lista aquí, que obviamente se ve

44
00:03:42,690 --> 00:03:47,860
desde el mismo sitio pero desde una carpeta diferente.

45
00:03:47,860 --> 00:03:51,820
Esto es aceptable, porque el origen, en este caso,

46
00:03:51,820 --> 00:03:55,420
el protocolo utilizado y el número de puerto, sigue siendo el mismo.

47
00:03:55,420 --> 00:04:00,660
Por lo tanto, esto es aceptable para acceder a este recurso.

48
00:04:00,660 --> 00:04:05,470
Del mismo modo, en el segundo caso, podríamos tener bajo

49
00:04:07,040 --> 00:04:10,570
varios niveles de subcarpetas un recurso al que se está accediendo.

50
00:04:10,570 --> 00:04:15,850
Pero de nuevo, ya que su origen sigue siendo el mismo, lo cual es aceptable.

51
00:04:15,850 --> 00:04:18,260
Pero veamos el tercer ejemplo aquí.

52
00:04:18,260 --> 00:04:23,930
En este ejemplo, vemos que estamos tratando de acceder a un recurso aquí con

53
00:04:23,930 --> 00:04:31,230
el protocolo https, que obviamente viola el mismo origen principal

54
00:04:31,230 --> 00:04:35,580
porque estamos usando un protocolo diferente para acceder a ese recurso en este punto.

55
00:04:35,580 --> 00:04:39,030
Así que eso sería considerado un fracaso en este caso.

56
00:04:39,030 --> 00:04:44,840
El cuarto caso es donde estamos accediendo a un recurso con un número de puerto diferente.

57
00:04:44,840 --> 00:04:50,300
Y el quinto caso es donde estamos accediendo a un recurso en un host diferente.

58
00:04:50,300 --> 00:04:54,830
Ahora, todos estos tres serían marcados como no válidos o

59
00:04:54,830 --> 00:04:58,110
no se puede acceder bajo esa política de origen.

60
00:04:58,110 --> 00:05:02,710
Por lo tanto, si impone la política del mismo origen para el acceso desde, por ejemplo,

61
00:05:02,710 --> 00:05:10,970
su XMLHttpRequest, entonces los últimos tres no estarían permitidos en este caso.

62
00:05:10,970 --> 00:05:16,270
Pero, por supuesto, hay muchas situaciones en las que ese diseñador

63
00:05:16,270 --> 00:05:22,510
de sitios puede alojar recursos en diferentes sitios, tal vez

64
00:05:22,510 --> 00:05:27,128
en diferentes dominios, y aún así poder extraer los datos para construir la página web o

65
00:05:27,128 --> 00:05:32,120
para hacer que la aplicación web se ejecute o para ejecutar la aplicación móvil híbrida .

66
00:05:32,120 --> 00:05:38,914
Por lo tanto, para acomodar estas situaciones, el

67
00:05:38,914 --> 00:05:44,798
manejo de solicitudes de origen cruzado es un método que nos permite acceder a estos recursos.

68
00:05:44,798 --> 00:05:50,410
Por lo tanto, consideramos que una solicitud es una

69
00:05:50,410 --> 00:05:56,290
solicitud de origen cruzado si está intentando acceder a un recurso desde un dominio diferente,

70
00:05:56,290 --> 00:06:01,240
o en un número de puerto diferente, o con un protocolo diferente.

71
00:06:01,240 --> 00:06:06,920
Entonces, ¿cómo podemos acomodar situaciones en las que este es un acceso legítimo a un recurso,

72
00:06:06,920 --> 00:06:08,800
pero debido a la política del mismo origen,

73
00:06:08,800 --> 00:06:12,930
su navegador se negará a cargar este recurso?

74
00:06:12,930 --> 00:06:15,790
Ahora es aquí donde, como mencioné,

75
00:06:15,790 --> 00:06:20,220
muchos navegadores restringirán las solicitudes http de origen cruzado,

76
00:06:20,220 --> 00:06:26,420
especialmente aquellas que son iniciadas por XMLHttpRequest o

77
00:06:26,420 --> 00:06:30,570
el protocolo Fetch para obtener datos.

78
00:06:30,570 --> 00:06:36,980
Estos son relevantes cuando accedemos a ellos desde nuestro código JavaScript.

79
00:06:36,980 --> 00:06:41,950
Por lo tanto, en esas circunstancias, tiene sentido imponer la política del mismo origen,

80
00:06:41,950 --> 00:06:46,490
pero entonces deberíamos tener una forma de solucionar la situación en la que

81
00:06:46,490 --> 00:06:49,980
se puede emitir una solicitud legítima.

82
00:06:49,980 --> 00:06:52,184
Aquí es donde nos

83
00:06:52,184 --> 00:06:56,960
ayuda el enfoque CORS, el enfoque de intercambio de recursos de origen cruzado.

84
00:06:56,960 --> 00:07:02,021
Por lo tanto, este CORS es un mecanismo que permite a los servidores web realizar

85
00:07:02,021 --> 00:07:06,741
solicitudes entre dominios o solicitudes de origen cruzado.

86
00:07:06,741 --> 00:07:10,400
Así que aquí el navegador y el servidor

87
00:07:10,400 --> 00:07:14,375
desde el que está tratando de arreglar el recurso interactuarán entre sí y

88
00:07:14,375 --> 00:07:20,945
luego llegarán a un acuerdo diciendo que este acceso es aceptable y permitido.

89
00:07:20,945 --> 00:07:23,575
Entonces, una vez que se alcanza el acuerdo,

90
00:07:23,575 --> 00:07:29,182
entonces esta solicitud puede ser permitida por su navegador.

91
00:07:29,182 --> 00:07:32,912
Por lo tanto, el navegador y el servidor interactuarán entre sí para

92
00:07:32,912 --> 00:07:38,252
determinar si este acceso a este recurso es una situación aceptable.

93
00:07:38,252 --> 00:07:43,672
Así que aquí es donde se introdujo un nuevo conjunto de encabezados HTTP

94
00:07:43,672 --> 00:07:49,010
en los mensajes de respuesta HTTP procedentes del lado del servidor.

95
00:07:49,010 --> 00:07:54,580
Estos encabezados permiten a los servidores describir el conjunto de orígenes a

96
00:07:54,580 --> 00:08:01,690
los que el servidor permite que el navegador acceda.

97
00:08:01,690 --> 00:08:06,760
Y a su vez, el navegador se da cuenta de que estos accesos

98
00:08:06,760 --> 00:08:11,405
a recursos son aceptables para ser permitidos, a pesar

99
00:08:11,405 --> 00:08:16,230
de que están violando esa política del mismo origen que hemos visto anteriormente.

100
00:08:16,230 --> 00:08:19,876
Entonces, en este caso, tenemos encabezados como, por ejemplo,

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

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

103
00:08:29,780 --> 00:08:35,330
algunos otros que el servidor utiliza para informar al navegador, diciendo que

104
00:08:35,330 --> 00:08:41,190
esta es una forma aceptable de acceder a el recurso desde el lado del navegador.

105
00:08:41,190 --> 00:08:46,970
Y cuando el navegador ve estos mensajes de respuesta entrantes desde el lado del servidor,

106
00:08:46,970 --> 00:08:52,510
el navegador acepta y permite que se realice esta solicitud de origen cruzado.

107
00:08:52,510 --> 00:08:56,500
Ahora, esto también significa que el servidor debe estar configurado para poder

108
00:08:56,500 --> 00:09:01,230
responder con estos campos de encabezado y

109
00:09:01,230 --> 00:09:06,800
la información de encabezado incluida en el mensaje de respuesta proveniente del lado del servidor.

110
00:09:06,800 --> 00:09:11,424
Ahora, aquí es donde dividimos todas las solicitudes de origen cruzado en

111
00:09:11,424 --> 00:09:13,260
varias categorías.

112
00:09:13,260 --> 00:09:18,495
Tenemos la primera es la simple solicitud entre sitios.

113
00:09:18,495 --> 00:09:22,780
En solicitudes simples entre sitios, es posible que esté usando GET o

114
00:09:22,780 --> 00:09:25,410
POST con el cuerpo de la solicitud.

115
00:09:25,410 --> 00:09:30,180
Pero cuando está utilizando la POST, su cuerpo de solicitud debe

116
00:09:30,180 --> 00:09:34,688
contener Application/X-WWW-urlenCoded,

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

118
00:09:39,305 --> 00:09:44,805
Luego se trata como una simple solicitud entre sitios y

119
00:09:44,805 --> 00:09:47,625
no se permitirán encabezados personalizados en este caso.

120
00:09:47,625 --> 00:09:52,955
Entonces, en este caso, es aceptable que el servidor informe al cliente,

121
00:09:52,955 --> 00:09:57,520
diciendo que esto está permitido y el navegador debe permitir tales solicitudes.

122
00:09:57,520 --> 00:10:01,700
Entonces, por ejemplo, para recursos de acceso amplio, como, por ejemplo,

123
00:10:01,700 --> 00:10:05,830
si realiza una solicitud GET a un servidor para obtener los datos para

124
00:10:05,830 --> 00:10:10,580
construir la interfaz de usuario, entonces tal vez la solicitud GET sea aceptable

125
00:10:10,580 --> 00:10:14,400
independientemente del origen de que se oriente esa solicitud.

126
00:10:14,400 --> 00:10:17,350
Entonces, en ese caso, su servidor responderá al cliente,

127
00:10:17,350 --> 00:10:23,250
diciendo Access-Conrol-Allow-Origin, con esa estrella comodín aquí,

128
00:10:23,250 --> 00:10:27,830
lo que significa que cualquier origen que origina la solicitud es aceptable, y

129
00:10:27,830 --> 00:10:33,540
el navegador debe permitir que la solicitud se realice a ese servidor.

130
00:10:33,540 --> 00:10:38,020
Y ahora, también puede restringir el acceso al origen.

131
00:10:38,020 --> 00:10:44,440
En este caso, puede decir específicamente que si el origen es

132
00:10:44,440 --> 00:10:50,090
un sitio en particular, entonces es aceptable dar servicio a esta solicitud.

133
00:10:50,090 --> 00:10:55,940
Por lo tanto, el navegador ve que enviar solicitudes

134
00:10:55,940 --> 00:11:01,230
con este sitio de origen en particular en la solicitud es aceptable y

135
00:11:01,230 --> 00:11:03,830
permitiremos la solicitud de origen cruzado.

136
00:11:03,830 --> 00:11:08,790
Por lo tanto, puede controlar la forma en que se

137
00:11:08,790 --> 00:11:12,870
especifica el origen en el mensaje de solicitud que proviene del lado del cliente.

138
00:11:12,870 --> 00:11:17,500
Por lo tanto, el servidor puede aceptar tales solicitudes.

139
00:11:17,500 --> 00:11:23,094
Algunas otras solicitudes se incluirían en la categoría de solicitudes preatendidas.

140
00:11:23,094 --> 00:11:27,750
En la solicitud previa, se espera que antes de que el cliente

141
00:11:27,750 --> 00:11:32,380
envíe la solicitud real, el cliente enviará una solicitud de comprobación previa,

142
00:11:32,380 --> 00:11:37,260
lo que significa que se pone en contacto con el servidor para obtener

143
00:11:37,260 --> 00:11:41,380
información del servidor antes de que se emita la solicitud real.

144
00:11:41,380 --> 00:11:46,580
Este es específicamente el caso en el que emite solicitudes PUT y DELETE

145
00:11:46,580 --> 00:11:52,160
porque las solicitudes PUT y DELETE pueden causar cambios en el lado del servidor.

146
00:11:52,160 --> 00:11:58,100
Por lo tanto, cualquier método que cause efectos secundarios en los datos del servidor, como la

147
00:11:58,100 --> 00:12:03,538
solicitud PUT y DELETE, tiene el mandato especial de seguir el enfoque de comprobación previa.

148
00:12:03,538 --> 00:12:08,276
En el enfoque de comprobación previa, la idea es que el cliente

149
00:12:08,276 --> 00:12:12,919
primero enviará una solicitud HTTP OPTIONS al lado del servidor, y

150
00:12:12,919 --> 00:12:19,174
en respuesta a ese mensaje de solicitud OPTIONS desde el lado del cliente, el servidor

151
00:12:19,174 --> 00:12:24,864
responderá con los correspondientes Access-Control-Allow-Headers,

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

153
00:12:31,504 --> 00:12:36,350
información del encabezado Access-Control-Allow-Credenciales en la respuesta a un mensaje OPTIONS.

154
00:12:36,350 --> 00:12:42,359
A partir de entonces, el cliente decidirá si puede emitir la solicitud de origen cruzado o

155
00:12:42,359 --> 00:12:48,870
no basándose en la respuesta a la solicitud de comprobación previa OPTIONS que el cliente envió.

156
00:12:48,870 --> 00:12:53,410
Entonces, aquí es donde debe pasar por dos pasos antes de que su solicitud

157
00:12:53,410 --> 00:12:57,205
pueda ser permitida y atendida por el lado del servidor.

158
00:12:58,340 --> 00:13:03,230
Una tercera categoría de solicitudes CORS sería lo que se denominan solicitudes con credenciales,

159
00:13:03,230 --> 00:13:07,900
donde espera que el cliente incluya credenciales en el encabezado

160
00:13:07,900 --> 00:13:09,608
del mensaje de solicitud.

161
00:13:09,608 --> 00:13:13,518
Entonces, las solicitudes que van acompañadas de cookies, por ejemplo, para

162
00:13:13,518 --> 00:13:19,040
reconocer la sesión en el lado del servidor, o algún tipo de

163
00:13:19,040 --> 00:13:24,440
información de autenticación HTTP en el encabezado de autorización en el mensaje de solicitud.

164
00:13:24,440 --> 00:13:27,843
Entonces, en este caso, el servidor necesita responder con

165
00:13:27,843 --> 00:13:32,460
Access-Control-Allow-Credenciales: true para el lado del cliente.

166
00:13:32,460 --> 00:13:37,920
Entonces, en este caso, el servidor responderá con esto y

167
00:13:37,920 --> 00:13:41,070
luego el cliente podrá enviar su

168
00:13:41,070 --> 00:13:45,720
información de credenciales en la solicitud entrante desde el lado del cliente.

169
00:13:45,720 --> 00:13:50,430
Ahora, en este caso, el Access-Control-Allow-Origin no puede

170
00:13:50,430 --> 00:13:56,550
tener el comodín, la estrella, en el mensaje de respuesta.

171
00:13:56,550 --> 00:14:00,770
Se espera que especifique explícitamente el origen al

172
00:14:00,770 --> 00:14:03,450
que se puede iniciar la solicitud.

173
00:14:04,500 --> 00:14:08,235
Ahora, obviamente, podemos implementar gran parte del trabajo,

174
00:14:08,235 --> 00:14:13,796
lo que tenemos que hacer en el lado del servidor, implementando nuestro propio middleware si así lo

175
00:14:13,796 --> 00:14:19,260
decidimos manejar las respuestas relacionadas con CORS desde el lado del servidor.

176
00:14:19,260 --> 00:14:23,570
Es muy sencillo, como hemos visto en el código que hemos implementado.

177
00:14:23,570 --> 00:14:29,140
Por supuesto, esa es una forma de manejar las respuestas relacionadas con CORS desde el lado del servidor

178
00:14:29,140 --> 00:14:34,800
, pero afortunadamente, tenemos un NODemodule CORS específico

179
00:14:34,800 --> 00:14:40,470
que está diseñado para manejar este tipo de

180
00:14:40,470 --> 00:14:44,920
trabajo que el servidor necesita hacer para cumplir con los requisitos de CORS.

181
00:14:44,920 --> 00:14:50,790
Por lo tanto, el CORS NodeModule nos permite configurar CORS en el lado del servidor,

182
00:14:50,790 --> 00:14:55,810
incluyendo la especificación de la información de origen donde se aceptarían

183
00:14:55,810 --> 00:15:01,010
las credenciales y muchos otros elementos de información

184
00:15:01,010 --> 00:15:05,630
para que pueda configurar el servidor para poder manejar las respuestas relacionadas con CORS que necesita dar

185
00:15:05,630 --> 00:15:09,480
al navegador en respuesta al mensaje de solicitud.

186
00:15:09,480 --> 00:15:15,750
Para instalar CORS NodeModule, obviamente ve npm install cors

187
00:15:15,750 --> 00:15:22,280
y luego configure el middleware CORS dentro de su aplicación express.

188
00:15:23,430 --> 00:15:28,940
El propio módulo CORS proporciona una forma muy sencilla de habilitar CORS.

189
00:15:28,940 --> 00:15:35,970
Simplemente puede incluir el uso de la aplicación CORS con corchetes vacíos, y

190
00:15:35,970 --> 00:15:41,370
eso significa esencialmente que está abriendo su servidor, y responderá con

191
00:15:41,370 --> 00:15:47,180
Access-Control-Allow-Origin con la estrella comodín a cada solicitud entrante.

192
00:15:47,180 --> 00:15:51,940
Pero cuando está configurando su servidor, es posible que desee más control sobre eso, por lo

193
00:15:51,940 --> 00:15:57,190
que es donde podemos especificar opciones adicionales para CORS.

194
00:15:57,190 --> 00:16:02,790
Y no solo eso, puede imponer el manejo de CORS de

195
00:16:02,790 --> 00:16:06,810
manera diferente para diferentes rutas dentro de su servidor.

196
00:16:06,810 --> 00:16:12,320
Como veremos en el ejercicio, impondremos diferentes requisitos CORS en las

197
00:16:12,320 --> 00:16:17,540
diferentes rutas del lado del servidor, y todo esto se configura mediante el uso de

198
00:16:17,540 --> 00:16:22,690
varias opciones de configuración que el CORS NodeModule soporta para nosotros.

199
00:16:22,690 --> 00:16:28,620
Por lo tanto, usando CORS NodeModule, es muy fácil configurar su servidor para manejar

200
00:16:28,620 --> 00:16:34,020
cualquier solicitud de origen cruzado que llegue desde su lado cliente y

201
00:16:34,020 --> 00:16:39,730
luego responder con la información de encabezado adecuada al lado del cliente

202
00:16:39,730 --> 00:16:45,310
con los encabezados CORS apropiados en el mensaje de respuesta desde el lado del servidor.

203
00:16:45,310 --> 00:16:48,450
Con esta rápida comprensión de CORS,

204
00:16:48,450 --> 00:16:54,730
estoy seguro de que tiene más preguntas en este punto que respuestas de esta conferencia.

205
00:16:54,730 --> 00:16:58,960
Pero si desea leer muchos más detalles sobre CORS,

206
00:16:58,960 --> 00:17:04,050
le he proporcionado recursos adicionales al final de esta lección,

207
00:17:04,050 --> 00:17:06,804
que le permiten leer más sobre CORS en sí.

208
00:17:06,804 --> 00:17:11,553
Pero desde la perspectiva de este curso, nos gustaría configurar nuestra

209
00:17:11,553 --> 00:17:15,037
aplicación expresa que hemos estado desarrollando

210
00:17:15,037 --> 00:17:19,150
hasta ahora para manejar asuntos relacionados con CORS en el lado del servidor.

211
00:17:19,150 --> 00:17:24,941
Así que pasando al ejercicio, instalaremos el módulo CORS npm y

212
00:17:24,941 --> 00:17:30,236
luego lo configuraremos en varias rutas dentro de nuestro servidor adicional.

213
00:17:30,236 --> 00:17:33,629
[ MÚSICA]