[MÚSICA]
Vamos falar em alguma linguagem CORS agora.
Agora, o que exatamente é compartilhamento de resultados de origem cruzada, e
por que é relevante quando olhamos para aplicativos web e
aplicativos hipermóveis como temos feito nesta especialização?
Como você entende, a maioria das páginas da Web agora obtém dados de
muitos sites diferentes, a fim de construir uma página da Web.
Agora, a fim de impor uma política rigorosa de acesso a recursos de diferentes sites,
a mesma política de origem tem sido imposta por muitos navegadores.
Vamos falar um pouco sobre isso com mais detalhes nos próximos slides, mas
no contexto dos frameworks que temos discutido nesta
especialização em particular, como Angular, Ionic e NativeScript,
muitos deles envolverão scripts, código JavaScript,
que podem ter que acessar recursos de diferentes sites.
E é aqui que o problema CORS surge muito facilmente.
Vamos ver como vamos abordar esta questão com mais detalhes nesta palestra e
no exercício que se segue.
Eu brevemente aludi à política de mesma origem que comecei esta palestra.
Agora, a política de mesma origem é um modelo de segurança de aplicativo da Web
que restringe como um documento ou um script
carregado de uma origem interagem com recursos de outra origem.
O objetivo disso é isolar documentos potencialmente mal-intencionados.
Agora, obviamente, quando você tem uma página da Web que envolve script,
código JavaScript, que pode acessar recursos de outro local,
código potencialmente malicioso pode ser injetado em sua página da Web e
pelo qual acessar uma origem diferente de onde sua página da Web é obtida.
Agora, essa é a razão pela qual muitos navegadores impõem essa política de mesma origem.
Agora, quando falamos sobre a mesma origem, como especificamos uma origem?
Agora, neste contexto, uma origem para qualquer recurso é definida por três tuplas.
Primeiro, o protocolo que é usado para acessar o recurso.
Em segundo lugar, o nome do host do recurso ou o domínio desse recurso.
E em terceiro lugar, o número da porta na qual esse recurso está sendo acessado.
Então é assim que identificamos a origem de qualquer recurso. O
recurso neste caso pode ser uma página html, uma imagem,
dados JSON obtidos a partir de um ponto final da API REST e muito mais.
Para aprofundar a política de mesma origem, vejamos um exemplo.
Suponha que temos uma página da Web que é carregada a partir deste site listado aqui,
www.abc.com, e em uma pasta xyz, e
o page.html sendo carregado aqui.
Esta página pode envolver links ou até mesmo código JavaScript que pode
emitir XMLHttpRequest para outros recursos na página da Web.
Agora, neste caso, se tentarmos acessar outro URL, por
exemplo, o primeiro listado aqui, que obviamente você vê é
do mesmo site, mas de uma pasta diferente.
Isso é aceitável, porque a origem, neste caso,
o protocolo que está sendo usado e o número da porta, permanece a mesma.
Então, isso é aceitável para acessar esse recurso.
Da mesma forma, no segundo caso, podemos ter sob
vários níveis de subpastas um recurso que está sendo acessado.
Mas, novamente, uma vez que sua origem permanece a mesma, o que é aceitável.
Mas vejamos o terceiro exemplo aqui.
Neste exemplo, vemos que estamos tentando acessar um recurso aqui com
o protocolo https, que obviamente viola o principal de mesma origem
porque estamos usando um protocolo diferente para acessar esse recurso neste momento.
Então, isso seria considerado um fracasso neste caso.
O quarto caso é onde estamos acessando um recurso com um número de porta diferente.
E o quinto caso é onde estamos acessando um recurso em um host diferente.
Agora, todos esses três seriam marcados como não válidos ou não
podem ser acessados sob essa política de mesma origem.
Então, se você impor a política de mesma origem para acesso a partir, por exemplo, do
seu XMLHttpRequest, então os três últimos não serão permitidos neste caso.
Mas, é claro, há muitas situações em que esse designer de site
pode realmente hospedar recursos em sites diferentes, talvez em domínios diferentes,
e ainda ser capaz de extrair os dados para construir a página da Web ou
para fazer o aplicativo web executar ou para fazer o aplicativo móvel híbrido executar .
Então, para acomodar essas situações, o
tratamento de solicitações de origem cruzada é um método que nos permite acessar esses recursos.
Portanto, consideramos uma solicitação para ser uma
solicitação de origem cruzada se você estiver tentando acessar um recurso de um domínio diferente,
ou em um número de porta diferente, ou com um protocolo diferente.
Então, como podemos acomodar situações em que este é um acesso legítimo a um recurso,
mas devido à política de mesma origem,
seu navegador se recusará a carregar esse recurso?
Agora é aqui que, como mencionei,
muitos navegadores restringirão solicitações http de origem cruzada,
especialmente aquelas que são iniciadas por XMLHttpRequest ou
pelo protocolo Fetch para buscar dados.
Estes são relevantes quando os acessamos a partir de nosso código JavaScript.
Por conseguinte, nestas circunstâncias, faz sentido impor a política de mesma origem,
mas então deveríamos ter uma forma de contornar a situação em que
um pedido legítimo pode ser emitido.
É aqui que a abordagem CORS,
a abordagem de partilha de recursos de origem cruzada, vem em nosso auxílio.
Portanto, este CORS é um mecanismo que permite que os servidores Web executem
solicitações entre domínios ou solicitações de origem cruzada.
Então aqui o navegador e o servidor
de onde você está tentando corrigir o recurso irão interagir uns com os outros e
, em seguida, chegar a um acordo dizendo que esse acesso é aceitável e permitido.
Assim, uma vez que o acordo é alcançado,
então este pedido pode ser permitido pelo seu navegador.
Assim, o navegador e o servidor irão interagir uns com os outros, a fim de
determinar se este acesso a este recurso é uma situação aceitável.
Então é aqui que um novo conjunto de cabeçalhos HTTP foram
introduzidos nas mensagens de resposta HTTP provenientes do lado do servidor.
Esses cabeçalhos permitem que os servidores descrevam o conjunto de origens
que são permitidas pelo servidor para ser acessado pelo navegador.
E, por sua vez, o navegador percebe que esses acessos de recursos
são aceitáveis para serem permitidos, mesmo que eles estejam violando a
política de mesma origem que vimos anteriormente.
Então, neste caso, temos cabeçalhos como, por exemplo,
Access-Control-Allow-Origin, Access-Control-Allow-Credentials,
Access-Control-Allow-Headers, Access-Control-Allow-Methods, e
alguns outros que o servidor usa para informar o navegador, dizendo que
esta é uma maneira aceitável de acessar o recurso do lado do navegador.
E quando o navegador vê essas mensagens de resposta recebidas do lado do servidor,
o navegador aceita e permite que essa solicitação de origem cruzada seja executada.
Agora, isso também significa que o servidor deve ser configurado para ser capaz de
responder com esses campos de cabeçalho e
as informações de cabeçalho incluídas na mensagem de resposta vinda do lado do servidor.
Agora, é aqui que dividimos todas as solicitações de origem cruzada em
várias categorias.
Temos o primeiro a ser o simples pedido cross-site.
Em solicitações simples entre sites, você pode estar usando o GET ou
o POST com o corpo da solicitação.
Mas quando você estiver usando o POST, seu corpo de solicitação deve conter
application/X-www-urlencoded,
ou multipart/form-data, ou text/plain.
Em seguida, ele é tratado como uma simples solicitação entre sites e
nenhum cabeçalho personalizado será permitido neste caso.
Assim, neste caso, é aceitável que o servidor informe o cliente,
dizendo que isso é permitido e o navegador deve permitir tais solicitações.
Então, por exemplo, para recursos amplamente acessados, como, por exemplo,
se você executar uma solicitação GET para um servidor a fim de buscar os dados a fim de
construir a interface do usuário, então talvez a solicitação GET seja aceitável
independentemente da origem da solicitação.
Então, nesse caso, seu servidor responderá ao cliente,
dizendo Access-Conrol-Allow-Origin, com essa estrela curinga aqui, o
que significa que qualquer origem que origine a solicitação é aceitável, e
o navegador deve permitir que a solicitação seja executada para esse servidor.
E agora, você também pode restringir o acesso à origem.
Neste caso, você pode dizer especificamente que, se a origem for
um site específico, é aceitável atender esta solicitação.
Assim, o navegador vê que o envio de solicitações
com este site de origem específico na solicitação é aceitável e
vamos permitir a solicitação de origem cruzada.
Assim, você pode controlar a forma como a origem é
especificada na mensagem de solicitação vinda do lado do cliente.
Assim, o servidor é capaz de aceitar tais solicitações.
Alguns outros pedidos estariam sob a categoria de pedidos predefinidos.
Na solicitação preflit, você espera que antes que o cliente envie
a solicitação real, o cliente enviará uma solicitação de comprovação, o
que significa que ele contata o servidor para obter
informações do servidor antes que a solicitação real seja emitida.
Este é especificamente o caso em que você emite solicitações PUT e DELETE
porque as solicitações PUT e DELETE podem causar alterações no lado do servidor.
Assim, qualquer método que cause efeitos colaterais nos dados do servidor, como o PUT e
a solicitação DELETE, são especialmente mandatados para seguir a abordagem de comprovação.
Na abordagem de comprovação, a idéia é que o cliente irá
primeiro enviar uma solicitação HTTP OPTIONS para o lado do servidor, e
em resposta a essa mensagem de solicitação OPTIONS do lado do cliente, o servidor
responderá com o Access-Control-Allow-Headers correspondentes,
Access-Control-Allow-Origin, e
informações de cabeçalho Access-Control-Allow-Credentials na resposta a uma mensagem OPTIONS.
Posteriormente, o cliente decidirá se pode emitir a solicitação de origem cruzada ou
não com base na resposta à solicitação de comprovação OPTIONS que o cliente enviou.
Então é aqui que você tem que passar por duas etapas antes que sua solicitação
possa ser permitida e atendida pelo lado do servidor.
Uma terceira categoria de solicitações CORS seria o que são chamados de solicitações credenciadas,
onde você espera que o cliente inclua credenciais no cabeçalho
da mensagem de solicitação.
Assim, as solicitações que são acompanhadas por cookies, por exemplo, para
reconhecer a sessão no lado do servidor, ou algum tipo de
informações de autenticação HTTP no cabeçalho de autorização na mensagem de solicitação.
Então, neste caso, o servidor precisa responder com
Access-Control-Allow-Credentials: fiel ao lado do cliente.
Então, neste caso, o servidor responderá com isso e,
em seguida, o cliente terá permissão para enviar suas
informações de credenciais na solicitação de entrada do lado do cliente.
Agora, neste caso, o Access-Control-Allow-Origin não tem permissão
para ter o curinga, a estrela, na mensagem de resposta.
Espera-se especificar explicitamente a origem para a
qual a solicitação pode ser iniciada.
Agora, obviamente, podemos implementar grande parte do trabalho,
o que precisamos fazer no lado do servidor, implementando nosso próprio middleware se assim
optarmos por lidar com as respostas relacionadas ao CORS do lado do servidor.
É muito simples, como vimos no código que implementamos.
Claro, essa é uma maneira de lidar com respostas relacionadas ao CORS do lado do servidor,
mas felizmente, temos um CORS NodeModule específico
que é projetado para lidar com esse tipo de
trabalho que o servidor precisa fazer para atender aos requisitos CORS.
Assim, o CORS NodeModule nos permite configurar o CORS no lado do servidor,
incluindo especificar informações de origem onde as credenciais seriam aceitas
e muitas outras informações, de modo que você pode configurar o servidor
para ser capaz de lidar com respostas relacionadas a CORS que ele precisa fornecer para
o navegador em resposta à mensagem de solicitação.
Para instalar o CORS NodeModule, obviamente você vê npm install cors
e, em seguida, configurar o middleware CORS dentro de sua aplicação express.
O módulo CORS em si fornece uma maneira muito simples de ativar o CORS.
Você pode simplesmente incluir o uso do aplicativo CORS com colchetes vazios, e
isso significa essencialmente que você está abrindo seu servidor, e ele responderá com
o Access-Control-Allow-Origin com a estrela curinga para cada solicitação recebida.
Mas quando você está configurando seu servidor, você pode querer mais controle sobre isso, de modo
que é onde podemos especificar opções adicionais para o CORS.
E não só isso, você pode impor o manuseio de CORS de
forma diferente para diferentes rotas dentro do lado do servidor.
Então, como veremos no exercício, vamos impor diferentes requisitos CORS nas
diferentes rotas do lado do nosso servidor, e tudo isso é configurado usando
várias opções de configuração que o CORS NodeModule suporta para nós.
Então, usando o CORS NodeModule, é muito fácil configurar seu servidor para lidar com
quaisquer solicitações de origem cruzada provenientes do lado do cliente e, em
seguida, responder com informações de cabeçalho apropriadas para o lado do cliente
com cabeçalhos CORS apropriados na mensagem de resposta do lado do servidor.
Com esta rápida compreensão do CORS,
tenho certeza que você tem mais perguntas neste momento do que respostas desta palestra.
Mas se você gostaria de ler muito mais detalhes sobre CORS,
eu forneci recursos adicionais no final desta lição,
que permitem que você leia mais sobre o próprio CORS.
Mas do ponto de vista deste curso, gostaríamos de configurar nossa
aplicação expressa que temos vindo a desenvolver
até agora para lidar com assuntos relacionados ao CORS no lado do servidor.
Então, passando para o exercício, vamos instalar o módulo CORS npm e, em
seguida, configurá-lo em várias rotas dentro do nosso servidor extra.
[ MUSIC]