[MÚSICA]
Hablemos en algún lenguaje CORS ahora.
Ahora, ¿qué es exactamente compartir resultados de origen cruzado, y
por qué es relevante cuando miramos aplicaciones web y
aplicaciones hipermóviles como hemos estado haciendo en esta especialización?
Como usted entiende, la mayoría de las páginas web ahora extraen datos de
muchos sitios diferentes para construir una página web.
Ahora, con el fin de imponer una política estricta de acceso a los recursos de diferentes sitios,
la misma política de origen ha sido impuesta por muchos navegadores.
Hablaremos un poco de eso con más detalle en las próximas diapositivas, pero
en el contexto de los frameworks que hemos estado discutiendo en esta
especialización particular, como Angular, Ionic y NativeScript,
muchos de estos implicarán scripts, código JavaScript,
que podría tener que acceder a recursos de diferentes sitios.
Y aquí es donde el problema CORS surge muy fácilmente.
Veamos cómo abordaremos este tema con más detalle en esta conferencia y
el ejercicio que sigue.
He aludido brevemente a la política del mismo origen que he empezado esta conferencia.
Ahora, la política del mismo origen es un modelo de seguridad de aplicaciones web
que restringe cómo un documento o un script
cargado desde un origen interactuará con los recursos de otro origen.
El propósito de esto es aislar documentos potencialmente maliciosos.
Ahora, obviamente, cuando tiene una página web que involucra script,
código JavaScript, que podría acceder a recursos desde otra ubicación,
se podría inyectar código potencialmente malicioso en su página web y
por lo que acceder a un origen diferente al de donde se obtiene su página web.
Ahora, esa es la razón por la que muchos navegadores imponen esta política del mismo origen.
Ahora, cuando hablamos del mismo origen, ¿cómo especificamos un origen?
Ahora, en este contexto, un origen para cualquier recurso está definido por tres tuplas.
Primero, el protocolo que se utiliza para acceder al recurso.
En segundo lugar, el nombre de host del recurso o el dominio de ese recurso.
Y en tercer lugar, el número de puerto en el que se accede a ese recurso.
Así es como identificamos el origen de cualquier recurso. El
recurso en este caso podría ser una página html, una imagen,
datos JSON que se obtienen de un punto final de API REST y muchos más.
Para más detalles sobre la política del mismo origen, veamos un ejemplo.
Supongamos que tenemos una página web que se carga desde este sitio enumerado aquí,
www.abc.com, y en una carpeta xyz, y
el page.html que se está cargando aquí.
Esta página puede incluir enlaces o incluso código JavaScript que podría
emitir XMLHttpRequest a otros recursos de la página web.
Ahora, en este caso, si intentamos acceder a otra URL, por
ejemplo, la primera lista aquí, que obviamente se ve
desde el mismo sitio pero desde una carpeta diferente.
Esto es aceptable, porque el origen, en este caso,
el protocolo utilizado y el número de puerto, sigue siendo el mismo.
Por lo tanto, esto es aceptable para acceder a este recurso.
Del mismo modo, en el segundo caso, podríamos tener bajo
varios niveles de subcarpetas un recurso al que se está accediendo.
Pero de nuevo, ya que su origen sigue siendo el mismo, lo cual es aceptable.
Pero veamos el tercer ejemplo aquí.
En este ejemplo, vemos que estamos tratando de acceder a un recurso aquí con
el protocolo https, que obviamente viola el mismo origen principal
porque estamos usando un protocolo diferente para acceder a ese recurso en este punto.
Así que eso sería considerado un fracaso en este caso.
El cuarto caso es donde estamos accediendo a un recurso con un número de puerto diferente.
Y el quinto caso es donde estamos accediendo a un recurso en un host diferente.
Ahora, todos estos tres serían marcados como no válidos o
no se puede acceder bajo esa política de origen.
Por lo tanto, si impone la política del mismo origen para el acceso desde, por ejemplo,
su XMLHttpRequest, entonces los últimos tres no estarían permitidos en este caso.
Pero, por supuesto, hay muchas situaciones en las que ese diseñador
de sitios puede alojar recursos en diferentes sitios, tal vez
en diferentes dominios, y aún así poder extraer los datos para construir la página web o
para hacer que la aplicación web se ejecute o para ejecutar la aplicación móvil híbrida .
Por lo tanto, para acomodar estas situaciones, el
manejo de solicitudes de origen cruzado es un método que nos permite acceder a estos recursos.
Por lo tanto, consideramos que una solicitud es una
solicitud de origen cruzado si está intentando acceder a un recurso desde un dominio diferente,
o en un número de puerto diferente, o con un protocolo diferente.
Entonces, ¿cómo podemos acomodar situaciones en las que este es un acceso legítimo a un recurso,
pero debido a la política del mismo origen,
su navegador se negará a cargar este recurso?
Ahora es aquí donde, como mencioné,
muchos navegadores restringirán las solicitudes http de origen cruzado,
especialmente aquellas que son iniciadas por XMLHttpRequest o
el protocolo Fetch para obtener datos.
Estos son relevantes cuando accedemos a ellos desde nuestro código JavaScript.
Por lo tanto, en esas circunstancias, tiene sentido imponer la política del mismo origen,
pero entonces deberíamos tener una forma de solucionar la situación en la que
se puede emitir una solicitud legítima.
Aquí es donde nos
ayuda el enfoque CORS, el enfoque de intercambio de recursos de origen cruzado.
Por lo tanto, este CORS es un mecanismo que permite a los servidores web realizar
solicitudes entre dominios o solicitudes de origen cruzado.
Así que aquí el navegador y el servidor
desde el que está tratando de arreglar el recurso interactuarán entre sí y
luego llegarán a un acuerdo diciendo que este acceso es aceptable y permitido.
Entonces, una vez que se alcanza el acuerdo,
entonces esta solicitud puede ser permitida por su navegador.
Por lo tanto, el navegador y el servidor interactuarán entre sí para
determinar si este acceso a este recurso es una situación aceptable.
Así que aquí es donde se introdujo un nuevo conjunto de encabezados HTTP
en los mensajes de respuesta HTTP procedentes del lado del servidor.
Estos encabezados permiten a los servidores describir el conjunto de orígenes a
los que el servidor permite que el navegador acceda.
Y a su vez, el navegador se da cuenta de que estos accesos
a recursos son aceptables para ser permitidos, a pesar
de que están violando esa política del mismo origen que hemos visto anteriormente.
Entonces, en este caso, tenemos encabezados como, por ejemplo,
Access-Control-Allow-Origin, Access-Control-Allow-Credenciales,
Access-Control-Allow-Headers, Access-Control-Allow-Methods, y
algunos otros que el servidor utiliza para informar al navegador, diciendo que
esta es una forma aceptable de acceder a el recurso desde el lado del navegador.
Y cuando el navegador ve estos mensajes de respuesta entrantes desde el lado del servidor,
el navegador acepta y permite que se realice esta solicitud de origen cruzado.
Ahora, esto también significa que el servidor debe estar configurado para poder
responder con estos campos de encabezado y
la información de encabezado incluida en el mensaje de respuesta proveniente del lado del servidor.
Ahora, aquí es donde dividimos todas las solicitudes de origen cruzado en
varias categorías.
Tenemos la primera es la simple solicitud entre sitios.
En solicitudes simples entre sitios, es posible que esté usando GET o
POST con el cuerpo de la solicitud.
Pero cuando está utilizando la POST, su cuerpo de solicitud debe
contener Application/X-WWW-urlenCoded,
o multipart/form-data, o text/plain.
Luego se trata como una simple solicitud entre sitios y
no se permitirán encabezados personalizados en este caso.
Entonces, en este caso, es aceptable que el servidor informe al cliente,
diciendo que esto está permitido y el navegador debe permitir tales solicitudes.
Entonces, por ejemplo, para recursos de acceso amplio, como, por ejemplo,
si realiza una solicitud GET a un servidor para obtener los datos para
construir la interfaz de usuario, entonces tal vez la solicitud GET sea aceptable
independientemente del origen de que se oriente esa solicitud.
Entonces, en ese caso, su servidor responderá al cliente,
diciendo Access-Conrol-Allow-Origin, con esa estrella comodín aquí,
lo que significa que cualquier origen que origina la solicitud es aceptable, y
el navegador debe permitir que la solicitud se realice a ese servidor.
Y ahora, también puede restringir el acceso al origen.
En este caso, puede decir específicamente que si el origen es
un sitio en particular, entonces es aceptable dar servicio a esta solicitud.
Por lo tanto, el navegador ve que enviar solicitudes
con este sitio de origen en particular en la solicitud es aceptable y
permitiremos la solicitud de origen cruzado.
Por lo tanto, puede controlar la forma en que se
especifica el origen en el mensaje de solicitud que proviene del lado del cliente.
Por lo tanto, el servidor puede aceptar tales solicitudes.
Algunas otras solicitudes se incluirían en la categoría de solicitudes preatendidas.
En la solicitud previa, se espera que antes de que el cliente
envíe la solicitud real, el cliente enviará una solicitud de comprobación previa,
lo que significa que se pone en contacto con el servidor para obtener
información del servidor antes de que se emita la solicitud real.
Este es específicamente el caso en el que emite solicitudes PUT y DELETE
porque las solicitudes PUT y DELETE pueden causar cambios en el lado del servidor.
Por lo tanto, cualquier método que cause efectos secundarios en los datos del servidor, como la
solicitud PUT y DELETE, tiene el mandato especial de seguir el enfoque de comprobación previa.
En el enfoque de comprobación previa, la idea es que el cliente
primero enviará una solicitud HTTP OPTIONS al lado del servidor, y
en respuesta a ese mensaje de solicitud OPTIONS desde el lado del cliente, el servidor
responderá con los correspondientes Access-Control-Allow-Headers,
Access-Control-Allow-Origin, y la
información del encabezado Access-Control-Allow-Credenciales en la respuesta a un mensaje OPTIONS.
A partir de entonces, el cliente decidirá si puede emitir la solicitud de origen cruzado o
no basándose en la respuesta a la solicitud de comprobación previa OPTIONS que el cliente envió.
Entonces, aquí es donde debe pasar por dos pasos antes de que su solicitud
pueda ser permitida y atendida por el lado del servidor.
Una tercera categoría de solicitudes CORS sería lo que se denominan solicitudes con credenciales,
donde espera que el cliente incluya credenciales en el encabezado
del mensaje de solicitud.
Entonces, las solicitudes que van acompañadas de cookies, por ejemplo, para
reconocer la sesión en el lado del servidor, o algún tipo de
información de autenticación HTTP en el encabezado de autorización en el mensaje de solicitud.
Entonces, en este caso, el servidor necesita responder con
Access-Control-Allow-Credenciales: true para el lado del cliente.
Entonces, en este caso, el servidor responderá con esto y
luego el cliente podrá enviar su
información de credenciales en la solicitud entrante desde el lado del cliente.
Ahora, en este caso, el Access-Control-Allow-Origin no puede
tener el comodín, la estrella, en el mensaje de respuesta.
Se espera que especifique explícitamente el origen al
que se puede iniciar la solicitud.
Ahora, obviamente, podemos implementar gran parte del trabajo,
lo que tenemos que hacer en el lado del servidor, implementando nuestro propio middleware si así lo
decidimos manejar las respuestas relacionadas con CORS desde el lado del servidor.
Es muy sencillo, como hemos visto en el código que hemos implementado.
Por supuesto, esa es una forma de manejar las respuestas relacionadas con CORS desde el lado del servidor
, pero afortunadamente, tenemos un NODemodule CORS específico
que está diseñado para manejar este tipo de
trabajo que el servidor necesita hacer para cumplir con los requisitos de CORS.
Por lo tanto, el CORS NodeModule nos permite configurar CORS en el lado del servidor,
incluyendo la especificación de la información de origen donde se aceptarían
las credenciales y muchos otros elementos de información
para que pueda configurar el servidor para poder manejar las respuestas relacionadas con CORS que necesita dar
al navegador en respuesta al mensaje de solicitud.
Para instalar CORS NodeModule, obviamente ve npm install cors
y luego configure el middleware CORS dentro de su aplicación express.
El propio módulo CORS proporciona una forma muy sencilla de habilitar CORS.
Simplemente puede incluir el uso de la aplicación CORS con corchetes vacíos, y
eso significa esencialmente que está abriendo su servidor, y responderá con
Access-Control-Allow-Origin con la estrella comodín a cada solicitud entrante.
Pero cuando está configurando su servidor, es posible que desee más control sobre eso, por lo
que es donde podemos especificar opciones adicionales para CORS.
Y no solo eso, puede imponer el manejo de CORS de
manera diferente para diferentes rutas dentro de su servidor.
Como veremos en el ejercicio, impondremos diferentes requisitos CORS en las
diferentes rutas del lado del servidor, y todo esto se configura mediante el uso de
varias opciones de configuración que el CORS NodeModule soporta para nosotros.
Por lo tanto, usando CORS NodeModule, es muy fácil configurar su servidor para manejar
cualquier solicitud de origen cruzado que llegue desde su lado cliente y
luego responder con la información de encabezado adecuada al lado del cliente
con los encabezados CORS apropiados en el mensaje de respuesta desde el lado del servidor.
Con esta rápida comprensión de CORS,
estoy seguro de que tiene más preguntas en este punto que respuestas de esta conferencia.
Pero si desea leer muchos más detalles sobre CORS,
le he proporcionado recursos adicionales al final de esta lección,
que le permiten leer más sobre CORS en sí.
Pero desde la perspectiva de este curso, nos gustaría configurar nuestra
aplicación expresa que hemos estado desarrollando
hasta ahora para manejar asuntos relacionados con CORS en el lado del servidor.
Así que pasando al ejercicio, instalaremos el módulo CORS npm y
luego lo configuraremos en varias rutas dentro de nuestro servidor adicional.
[ MÚSICA]