‫Jonas: En esta conferencia
‫implementaremos algo llamado CORS, que significa intercambio de recursos de origen cruzado.
‫Y esta es una característica fundamental en cualquier API, pero
‫solo puedo mostrarte esto
‫ahora que la aplicación ya está implementada.
‫Ahora bien, ¿qué es realmente el intercambio de recursos entre
‫orígenes y por qué debemos implementarlo?
‫Bueno, digamos que tenemos nuestra API
‫aquí en natours-jonas. herokuapp. com / api / v1,
‫y así sucesivamente.
‫Y luego algún otro sitio web, por ejemplo, por ejemplo. com, está intentando
‫acceder a nuestra API.
‫Básicamente, estoy tratando de llamar a esta URL aquí.
‫Y esto se denomina solicitud de origen
‫cruzado, porque herokuapp. com es un dominio diferente
‫al ejemplo. com y, por lo tanto, if example. com está
‫intentando acceder a herokuapp. com, será
‫una solicitud de origen cruzado, ¿de acuerdo?
‫Ahora, por lo general, las solicitudes de origen cruzado no están
‫permitidas y, de forma predeterminada, fallarán, a menos que implementemos CORS, por
‫lo que el intercambio de recursos de origen cruzado.
‫Y dado que queremos que nuestra API
‫esté disponible para todos, definitivamente necesitamos implementar eso, ¿de acuerdo?
‫Ahora déjame mostrarte cómo fallaría esto.
‫Así que tomemos esta
‫URL aquí, abramos en su pestaña y luego inspeccionemos.
‫Entonces, básicamente, hagamos una solicitud HTTP a nuestra API aquí desde
‫la consola, ¿de acuerdo?
‫Porque básicamente cuando lo hagamos desde
‫aquí, también será una solicitud de origen cruzado.
‫Entonces, digamos que const x es igual a await,
‫y luego usemos la función de recuperación de JavaScript, ¿de acuerdo?
‫Así que buscar es básicamente
‫una función que es un poco similar a
‫la biblioteca Axios que usamos en
‫nuestro código, pero es JavaScript nativo en el
‫navegador, por lo que podemos usarlo aquí en la consola.
‫Entonces, digamos que queremos hacer una
‫solicitud a nuestra API de tours como esta, ¿de acuerdo?
‫Entonces, si intentamos esto ahora, veamos qué obtenemos.
‫Y de hecho obtenemos
‫el error de que intentar acceder a
‫esta ruta aquí desde este otro origen ha sido bloqueado por la política CORS.
‫Y eso es exactamente lo que dije antes.
‫De modo que, de forma predeterminada, siempre se bloqueará
‫una solicitud de origen cruzado.
‫Por cierto, esto solo se aplica a las solicitudes
‫realizadas desde el navegador.
‫Por ejemplo, usando la API de búsqueda aquí, o
‫algo como la biblioteca Axios que
‫usamos en nuestro código.
‫Y eso significa que desde
‫el servidor, siempre podremos realizar solicitudes de origen cruzado
‫sin ningún problema.
‫Así que no hay restricciones en el
‫servidor, sino solo en
‫el navegador, básicamente por razones de seguridad.
‫Ah, y también para que se considere origen cruzado, una
‫solicitud puede provenir de un dominio diferente.
‫Entonces, tal como vimos en nuestro primer ejemplo
‫aquí, pero también un subdominio diferente, un protocolo diferente
‫o incluso un puerto diferente se considera
‫una solicitud de origen cruzado.
‫Entonces, por ejemplo, si tuviéramos API. natours. com para nuestra API,
‫y luego haría una solicitud de natours. com, eso también
‫se consideraría una solicitud de origen
‫cruzado y fallaría, ¿de acuerdo?
‫Pero nuevamente, dado que queremos permitir que otros
‫sitios web accedan básicamente a nuestra
‫API, ahora implementemos el intercambio de recursos entre orígenes.
‫Muy bien, y lo hacemos una vez más
‫instalando un paquete NPM.
‫Entonces NPM instale, y simplemente CORS.
‫Entonces aquí necesitamos ese paquete.
‫Y una vez más, este CORS
‫aquí es una función
‫de middleware muy simple que ahora necesitamos usar para nuestra aplicación, ¿de acuerdo?
‫Así que hagamos eso aquí, ¿y por qué no hacerlo aquí
‫en la parte superior?
‫Digamos que implemente CORS.
‫Y así app. use, y luego llame a CORS,
‫que a su vez devolverá una función de middleware
‫que luego agregará un par de encabezados
‫diferentes a nuestra respuesta.
‫Y dado que toda esta función de middleware
‫aquí es básicamente agregar algunos encabezados específicos, tal vez esté
‫pensando "¿Por qué estamos usando" otro
‫paquete de NPM? "Bueno, echemos
‫un vistazo al código
‫de este paquete.
‫Entonces, GitHub CORS, una vez más, así
‫es como encuentro la documentación o el código
‫fuente en sí para mis paquetes.
‫Y entonces vayamos aquí a lib, que
‫generalmente significa biblioteca.
‫Y luego todo lo que realmente tenemos aquí es este índice. js.
‫Y entonces ves que aquí está todo el código, y
‫básicamente lo que
‫ves aquí es que simplemente agrega este encabezado
‫aquí con el valor de básicamente todo a los encabezados.
‫Muy bien, entonces tiene un par de
‫otros encabezados, Access-Control-Allow-Methods, allow-credentials, y eso
‫es para diferentes casos.
‫Está bien, pero para que vea
‫que en realidad todo se trata de encabezados aquí.
‫Así que sí, tal vez podríamos agregar estos encabezados por nosotros
‫mismos, pero ¿por qué haríamos eso?
‫Quiero decir que podríamos,
‫por supuesto, para comprender completamente cómo funciona, pero
‫en Node. js y
‫desarrollo Express, en el entorno real
‫normalmente no querrá reinventar la rueda y,
‫en su lugar, siempre que
‫pueda, utilice paquetes que otros desarrolladores hayan escrito para nosotros.
‫Así que realmente nos enfocamos en hacer que nuestra aplicación
‫funcione, en lugar de reescribir el código
‫que otros desarrolladores ya han escrito para nosotros, ¿de acuerdo?
‫Entonces, podemos echar un
‫vistazo a todo esto, pero como mencioné, también podemos
‫seguir adelante y usar esto, ¿de acuerdo?
‫De todos modos, así es como habilitamos el uso compartido de recursos entre orígenes
‫para todas las solicitudes entrantes.
‫Básicamente para toda nuestra API.
‫Pero digamos que solo queremos habilitar CORS
‫en una ruta específica.
‫Así que podríamos usar eso también, así que copiemos esto.
‫Entonces, si solo quisiéramos habilitar CORS, digamos en los
‫recorridos, bueno, podríamos simplemente
‫agregar eso aquí en esta pila de middleware.
‫Está bien, pero de nuevo en este caso
‫realmente queremos permitirlo en todas partes.
‫Entonces, como vimos anteriormente en el código
‫de GitHub,
‫lo que hace es configurar el encabezado Access-Control-Allow-Origin en todo.
‫Entonces, lo que significa todo
‫esto aquí es para todas las solicitudes, sin importar de dónde provengan.
‫Y esto es ideal para permitir que
‫todos consuman nuestra API.
‫Pero ahora imagine el
‫caso en el que no queremos compartir
‫nuestra API, pero queremos poder tener la API en un
‫dominio, o incluso en un subdominio, y
‫luego tener nuestra aplicación front-end en un dominio diferente.
‫Por ejemplo, digamos, como mencioné antes, teníamos nuestra
‫API en API. natours. com, pero luego
‫nuestra aplicación front-end en natours. com.
‫Entonces, en ese caso, todo lo
‫que queremos que haga es permitir el acceso desde este origen aquí, básicamente.
‫Y en ese caso usaríamos app. use, y luego CORS, y
‫luego pase un objeto para las opciones donde especificaríamos el
‫origen para decir HTTPS:
‫// www. natours. com.
‫Y este es solo un ejemplo
‫en caso de que tuviéramos nuestro front-end en natours. com, ¿de acuerdo?
‫Y así, de nuevo, con esto solo permitiríamos
‫esta URL básicamente, entonces este origen, para crear
‫solicitudes a la API. natours. com.
‫Y por supuesto también podríamos permitir otros orígenes.
‫Por ejemplo, solo para algunos sitios
‫web específicos que queremos que permita, ¿de acuerdo?
‫Pero nuevamente, en este caso realmente queremos permitir que todos.
‫Bien, esta fue la primera parte de habilitar CORS, pero en
‫realidad eso no es todo, porque
‫en este momento esto solo
‫funcionará para las llamadas solicitudes simples.
‫Y las solicitudes simples son solicitudes de obtención y publicación.
‫Por otro lado, tenemos las llamadas solicitudes no simples.
‫Y estos son solicitudes de colocación, parche y eliminación,
‫o también solicitudes que envían cookies
‫o usan encabezados no estándar.
‫Y estas solicitudes no
‫simples, requieren una fase de verificación previa.
‫Entonces, siempre que haya una solicitud no simple,
‫el navegador emitirá automáticamente la
‫fase de verificación previa, y así es como funciona.
‫Entonces, antes de que ocurra la solicitud real,
‫y digamos una solicitud de eliminación,
‫el navegador primero realiza una solicitud de opciones
‫para determinar si la solicitud real es
‫segura para enviar.
‫Entonces, lo que eso significa para nosotros,
‫los desarrolladores, es que en nuestro servidor debemos responder realmente
‫a esa solicitud de opciones.
‫Y las opciones son realmente solo otro método
‫HTTP, así que como obtener, publicar o eliminar, ¿de acuerdo?
‫Entonces, básicamente, cuando recibimos una de estas solicitudes
‫de opciones en nuestro servidor,
‫necesitamos enviar el mismo encabezado Access-Control-Allow-Origin.
‫Y de esta manera, el navegador
‫sabrá que la
‫solicitud real, y en este caso la solicitud de eliminación,
‫es segura de realizar, y luego ejecutará la solicitud de eliminación, ¿de acuerdo?
‫Así que hagamos eso y digamos aplicación. opciones.
‫De acuerdo, y de nuevo, esto es muy similar a
‫hacer una aplicación. obtener, por ejemplo, o. correo, . Eliminar, . patch, y
‫todos estos verbos que ya conoces.
‫Tan . options no es establecer ninguna opción en
‫nuestra aplicación, en realidad es solo otro método HTTP al que podemos responder.
‫Y nuevamente, en este caso debemos responder porque el
‫navegador envía una solicitud de opción
‫cuando hay una fase de verificación previa.
‫Entonces, necesitamos definir la
‫ruta para la que queremos manejar las opciones.
‫Y una vez más, haremos esto en todas las rutas, ¿de acuerdo?
‫Y luego, básicamente, el controlador,
‫que una vez más es el middleware CORS, ¿de acuerdo?
‫Y una vez más, por supuesto, solo
‫podríamos permitir estas solicitudes complejas en una ruta específica.
‫Por ejemplo, app. opciones, y
‫digamos solo en api / v1 / tours
‫/: id, así, ¿de acuerdo?
‫Entonces, digamos que alguien hace una eliminación o una solicitud de parche
‫para uno de los recorridos, y solo allí
‫permitimos una fase de verificación previa.
‫Y, básicamente, solo en esta ruta
‫aquí, se puede realizar una de estas solicitudes complejas.
‫Entonces, en este caso aquí, donde solo teníamos esta ruta de opciones, solo
‫los recorridos se podían eliminar o
‫parchear desde una solicitud de origen cruzado, ¿verdad?
‫Y ninguno de nuestros otros recursos, ¿de acuerdo?
‫Pero una vez más, permitámoslos a todos, ¿de acuerdo?
‫Pero todavía te dejaré esto aquí como ejemplo.
‫Bien, de todos modos, eso es todo lo que realmente tenemos
‫que hacer para habilitar CORS para nuestra aplicación.
‫Entonces, ahora vuelva a implementar la
‫aplicación empujándola nuevamente a Heroku.
‫Pero antes de hacer eso, quiero cambiar algo aquí
‫en nuestro paquete. json.
‫Y ese es este motor de nodos aquí.
‫Entonces, a veces puede crear algunos
‫problemas cuando especificamos la versión de esta manera.
‫Entonces, básicamente, permitir que se instalen versiones que
‫son mayores que la versión
‫que estamos ejecutando actualmente.
‫Entonces, lo que quiero
‫hacer aquí es decir que solo debería instalar la versión
‫10, y no una versión posterior.
‫Así que lo hago diciendo este símbolo de intercalación aquí, y luego
‫la versión 10.
‫Y una vez más, eso es usar el control de versiones
‫semántico, y así como aquí.
‫Lo que recuerde, significa que NPM
‫puede instalar cualquiera de estas subversiones o versiones de
‫parche, pero no pasar a la siguiente versión principal.
‫Y aquí lo que estoy haciendo es lo mismo, ¿de acuerdo?
‫Entonces, actualmente estoy ejecutando Node versión 10, y
‫puedes confirmar el tuyo escribiendo node -v, y ves que estoy
‫en 10. 11 ahora mismo.
‫Pero probablemente cuando estés viendo este
‫curso, tendrás al menos la versión 12, tal vez incluso la 14 o la 16,
‫dependiendo de cuánto tiempo tengas en el futuro, ¿de acuerdo?
‫Y no se preocupe, por
‫supuesto, todo lo que le muestro aquí en el
‫curso debería funcionar
‫bien para cualquier versión de Node que esté usando.
‫Entonces, si está usando
‫la versión 12, entonces coloque la 12 aquí, ¿de acuerdo?
‫De todos modos, ahora agreguemos todos los archivos
‫modificados al área de preparación, así que git agrega todos.
‫Y luego envíelos con un mensaje significativo, así
‫que implementó CORS.
‫Y luego consigue empujar al maestro de Heroku.
‫Y ahora eso lleva algo de
‫tiempo, así que te veré cuando esté listo.
‫Entonces, la aplicación se implementó con éxito ahora, recarguemos
‫rápidamente aquí solo para ver
‫si todavía funciona, y de hecho lo está.
‫Y ahora, para demostrarle que funciona de manera diferente con CORS,
‫si hacemos esta
‫solicitud aquí nuevamente, debería funcionar, ¿verdad?
‫Intentémoslo, y aquí vamos.
‫No hay error esta vez, marquemos x aquí.
‫Y de hecho, parece que hay algo aquí.
‫Entonces ves que en realidad la respuesta es de
‫tipo CORS, tenemos nuestros encabezados, bueno, realmente no puedo verlos aquí.
‫Eso no importa, aquí también tenemos solo
‫una cadena legible, pero
‫nuevamente eso no es importante en absoluto.
‫Lo que importa aquí es
‫que ahora podemos realizar solicitudes de origen cruzado, por lo que es fantástico.
‫Ahora permítame mostrarle también los encabezados reales
‫que agrega el
‫paquete CORS simplemente haciendo una solicitud aquí en Postman.
‫Entonces, en producción, enviémoslo ahora.
‫Y aquí puede ver en
‫los encabezados de respuesta que en realidad
‫tenemos este Access-Control-Allow-Origin configurado para todo, está bien, genial.
‫Y así es como realmente implementa el uso compartido de
‫recursos de origen cruzado en su propia aplicación.