Trabalhando com CORS

O Cross-Origin Resource Sharing (CORS) é um protocolo baseado em cabeçalho que permite que JavaScript faça solicitações em seu nome para acessar recursos em outro domínio. Configure o Cloud Gate para que ele ative o CORS e imponha definições de CORS para o Cloud Gate em execução nos domínios de identidades do App Gateway ou do IAM.

O CORS ajuda a impedir que JavaScript desonesto (plantado em um site por invasores, por exemplo, usando anúncios) faça solicitações AJAX em seu nome. Solicitações AJAX fraudulentas podem retirar dinheiro do seu banco ou fazer compras em seu nome em um site de compras on-line. Essas solicitações podem ser bem-sucedidas se você tiver atualmente uma sessão ativa com esses sites. O CORS estipula que, se um servidor não responder com o conjunto correto de Cabeçalhos de Resposta, o browser não permitirá que o JavaScript veja (ou acesse) a resposta.

Uma solicitação CORS é acionada quando JavaScript tenta uma Solicitação HTTP para outra:

domínio - por exemplo, site1.oraclecloud.com chama oracle.com
subdomínio - por exemplo, site1.oraclecloud.com chama site7.oraclecloud.com
porta - por exemplo, site1.oraclecloud.com chama site1.oraclecloud.com:3030
protocolo - por exemplo, https://site1.oraclecloud.com chama http://site1.oraclecloud.com

Uma Solicitação CORS vem em duas formas: uma Solicitação CORS Simples ou uma Solicitação CORS Preflight.

Solicitação CORS Simples

Uma Solicitação CORS Simples será executada se a Solicitação JavaScript em relação a um recurso em outro domínio tiver as seguintes características:

O método é um dos seguintes:
- GET
- POST
- HEAD
Os Cabeçalhos HTTP permitidos que podem ser adicionados manualmente à Solicitação de CORS Simples são:
- Accept
- Accept-Language
- Content-Language
- Content-Type
- DPR
- Downlink
- Save-Data
- Viewport-Width
- Width
O Content-Type, se definido, deverá ser:
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain

Solicitação CORS de Preflight

Se a solicitação JavaScript não atender às características de uma Solicitação CORS Simples, uma Solicitação CORS de Preflight será enviada ao recurso localizado no outro domínio.

A Solicitação CORS de Pré-voo testa se a solicitação real pode ser enviada para esse recurso, incluindo cabeçalhos HTTP específicos na solicitação que contém os dados que resultaram no acionamento do fluxo de solicitação de pré-voo. Em outras palavras, se a Solicitação HTTP JavaScript tiver especificado alguns métodos/cabeçalhos na Solicitação HTTP que exigiram uma Solicitação CORS de Preflight, a Solicitação CORS de Preflight consultará o recurso para esses métodos/cabeçalhos para ver se o recurso aceita essa solicitação de domínio cruzado.

Propriedades e Atributos de Configuração CORS do Cloud Gate

A tabela a seguir descreve as propriedades e os atributos de configuração do CORS do Cloud Gate.


Propriedade CORS	Descrição
`cloudGateCorsEnabled`	Propriedade booliana para ativar o suporte CORS do Cloud Gate para a tenancy. Essa configuração deve ser configurada como: `true`. A ativação do flag `cloudGateCorsEnabled` em `cloudGateCorsSettings` ativa o recurso em seu tenant e os domínios de identidades imporão a lista de origens permitidas definidas em `cloudGateCorsAllowedOrigins` e uma lista global de origens permitidas. O padrão é `false`. Melhores práticas. Configure `cloudGateCorsAllowedOrigins` ao mesmo tempo. Se esta propriedade for deixada vazia, todas as Solicitações de CORS falharão.
`cloudGateCorsAllowedOrigins`	A propriedade é um Array de String que contém a lista de Origens CORS permitidas. O padrão é um array vazio. Cada Solicitação CORS especifica sua origem ou origem no Cabeçalho da Solicitação de Origem. O valor do Cabeçalho de Origem corresponde a esta lista. Se a Origem for correspondida, o Cloud Gate adicionará os Cabeçalhos CORS apropriados à sua resposta. Se a Origem não for correspondida, o Cloud Gate não retornará Cabeçalhos de Resposta de CORS, fazendo com que a resposta seja rejeitada pelo browser. Valores CORS permitidos no modelo de entrada: Entrada: `* \| <PROTOCOL>"://"<HOST><PORT>` `<PROTOCOL>`: `* \| http \| https` `<HOST>`: `[<DOMAIN>.]<DOMAIN>` `<DOMAIN>`: `< any alphanumerical character, * and - >` Um `<DOMAIN>` não pode iniciar ou terminar com um '`-`'. Qualquer `<DOMAIN>` pode ser um curinga. O curinga deve incluir o domínio inteiro. Por exemplo, `www..com` é válido, mas `www.racle.com` não é. Use https://tools.ietf.org/html/rfc1123 como referência `<PORT>`: `<EMPTY> \| ":" <PORT_VALUE>` `<PORT_VALUE>`: `* \| <numerical characters>`. `<PORT_VALUE>` deve estar na faixa de 1 a 65535. Exemplos: Combine tudo: `` Correspondência exata: `https://www.acme.com, https://www.acme.com:4443` Host/protocolo exato, qualquer porta: `https://www.google.com:` Host/porta exato, qualquer protocolo (HTTP ou HTTPS): `://www.acme.com, ://www.acme.com:8080` Subdomínio, protocolo exato, sem porta: `https://.oraclecloud.com` Qualquer domínio, protocolo exato, sem porta: `https://`
`cloudGateCorsAllowNullOrigin`	Propriedade booleana para suportar cenários em que o navegador envia uma Origem "nula". Essa definição deve ser configurada como: `true`. O padrão é `false`. Uma Origem "nula" será enviada se a Solicitação de CORS for proveniente de um arquivo no computador de um usuário ou se um servidor redirecionar para outro servidor em resposta a uma Solicitação de CORS. O navegador passa uma Origem "nula" quando considera a Origem "manchada". Para aumentar a segurança, por padrão, Origens "nulas" não são permitidas. Algumas Origens "nulas" são válidas. Os aplicativos que utilizam o Log-in no Fluxo do Browser do OpenID Connect (OIDC) do domínio de identidades verão Origens "nulas" enviadas ao(s) nó(s) do Cloud Gate. Quando o Cloud Gate redireciona para o ponto final de autorização do domínio de identidades para iniciar o Log-in no Browser do OIDC e quando o domínio de identidades redireciona a solicitação de volta para o Cloud Gate, a Origem será "nula".
`cloudGateCorsMaxAge`	Um inteiro que especifica o número de segundos que o cliente (navegador) pode armazenar em cache uma Resposta CORS de Preflight.
`cloudGateCorsExposedHeaders`	A propriedade é um Array de String que lista os Cabeçalhos de Resposta que podem ser adicionados ao Cabeçalho de Resposta `Access-Control-Expose-Headers`. O padrão é um array vazio.

Configurando Definições de CORS do Cloud Gate em Domínios de Identidades

O Cloud Gate requer que você configure as seguintes definições em domínios de identidade para suporte ao CORS (Compartilhamento de Recursos entre Origens).

Antes de iniciar a configuração, certifique-se de ter a versão correta do Cloud Gate. Versões anteriores do módulo Cloud Gate não forneciam suporte para CORS. Foi deixado para Aplicativos Protegidos para suportar CORS. Se a definição isCorsAllowed no documento da Política da Camada Web fosse configurada como true, o Cloud Gate permitiria solicitações CORS de pré-voo por meio de Aplicativos Protegidos.

Observação

A versão mínima necessária do Cloud Gate é a 21.1.2.

Use o ponto final /admin/v1/Settings/Settings para configurar as definições de CORS. A solicitação é uma operação patch. Consulte Atualizar uma Definição para obter mais informações.

Use este payload de amostra como modelo para criar o corpo da solicitação. Salve o payload em um arquivo, por exemplo, /tmp/cors-settings.json. Edite o arquivo com os detalhes da sua implantação.

Amostra de payload.

   {
   "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
   "Operations": [{
    "op": "replace",
    "path": "cloudGateCorsSettings",
    "value": {
    "cloudGateCorsEnabled": true,
    "cloudGateCorsAllowNullOrigin": true,
    "cloudGateCorsAllowedOrigins": [ "https://app.my-server.com:8080", "https://*:*" ],
    "cloudGateCorsMaxAge: 60,
    "cloudGateCorsExposedHeaders": [ "x-custom-header", "x-my-app-header" ]
    }
    }]
   }

Exemplo de solicitação cURL.

   # $AT is a previously generated Admin Access Token.
   # https://<IdentityDomainID>.identity.oraclecloud.com is an example URL 
   $ curl -X PATCH -H "Content-Type: application/scim+json" -H "Accept: application/json" -H "Authorization: Bearer $AT" "https://<domainURL>/admin/v1/Settings/Settings" --data @"/tmp/cors-settings.json"

Execute um dos procedimentos a seguir para ativar o suporte a CORS.
- Reinicie ou recarregue manualmente o servidor NGINX.
- Aguarde até que o cache de definições de CORS do Cloud Gate expire. Isso pode levar até uma hora, por padrão.
A seguir estão os cabeçalhos de resposta CORS que o Cloud Gate retorna, dependendo da solicitação CORS.
- Access-Control-Allow-Origin
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- Access-Control-Allow-Credentials
- Access-Control-Max-Age
- Access-Control-Expose-Headers

Workflows de Solicitação CORS Simples e Preflight

Visão geral dos fluxos de trabalho de solicitação de CORS (Compartilhamento de recursos entre origens).

Workflow de Solicitação CORS Simples

A Solicitação é identificada como uma Solicitação CORS pela presença do Cabeçalho da Solicitação de Origem.
Se necessário (por exemplo, expiração do cache), as definições CORS do Cloud Gate são baixadas dos domínios de identidades no IAM.
O Cloud Gate processa a solicitação - rejeitando a solicitação ou permitindo que ela passe para o servidor de aplicativos upstream.
Antes de uma resposta ser retornada, o Cloud Gate impõe o CORS conforme definido pelas definições de CORS do Cloud Gate.
1. O Cloud Gate sempre garante que o Cabeçalho Variar Resposta faça parte da Resposta - e contenha o Cabeçalho "Origem". Isso ocorre mesmo para solicitações não CORS.
2. Se cloudGateCorsEnabled for false, o processamento será interrompido aqui. A Resposta é retornada como está.
3. O Cloud Gate verifica se a Origem é permitida - usando a lista configurada de Origens Permitidas.
  Se a Origem não for permitida, todos os Cabeçalhos de Resposta CORS suportados serão retirados da Resposta e o processamento será encerrado.
4. O Cabeçalho de Resposta Access-Control-Allow-Origin é adicionado e configurado com o valor do Cabeçalho de Solicitação de Origem.
5. O Cabeçalho de Resposta Access-Control-Allow-Credentials é adicionado e configurado em true.
6. O Access-Control-Expose-Headers é configurado para a interseção entre o valor cloudGateCorsExposedHeaders e a lista de Cabeçalhos que estão sendo retornados na Resposta.
7. As opções Access-Control-Allow-Methods, Access-Control-Allow-Headers e Access-Control-Max-Age Response Headers são removidas da Resposta.
O Cloud Gate retorna sua Resposta.

Nota

O Cloud Gate substituirá os Cabeçalhos Access-Control-Allow-Origin e Access-Control-Allow-Credentials Response, se definidos pelo servidor de aplicativos upstream.

Workflow de Solicitação CORS de Preflight

A Solicitação é identificada como uma Solicitação CORS pela presença do Cabeçalho da Solicitação de Origem.
Se necessário (por exemplo, expiração do cache), as definições CORS do Cloud Gate são baixadas dos domínios de identidades no IAM.
A Solicitação é identificada como uma Solicitação CORS de Preflight pelo Método OPTIONS e pelo Cabeçalho da Solicitação Access-Control-Request-Method - além do Cabeçalho da Solicitação de Origem.
Se cloudGateCorsEnabled for true, a Solicitação poderá passar para o servidor de aplicativos upstream - para permitir que os aplicativos implementem o CORS.
Se cloudGateCorsEnabled for false, a configuração antiga da Política da Camada Web isCorsAllowed ainda será respeitada - apenas mais tarde no processamento da solicitação.
Antes de a resposta ser retornada do Cloud Gate, o CORS é imposto conforme definido pelas definições de CORS do Cloud Gate.
1. O Cloud Gate sempre garante que o Cabeçalho de Resposta Variada faça parte da Resposta - e contenha o Cabeçalho "Origem". Isso ocorre mesmo para Solicitações nonCORS.
2. Se cloudGateCorsEnabled for false, o processamento será interrompido aqui. A Resposta é retornada como está.
3. O Cloud Gate verifica se a Origem é permitida - usando a lista configurada de Origens Permitidas.
  Se a Origem não for permitida, todos os Cabeçalhos de Resposta CORS suportados serão retirados da Resposta e o processamento será encerrado.
4. O Cabeçalho de Resposta Access-Control-Allow-Origin é adicionado e configurado com o valor do Cabeçalho de Solicitação de Origem.
5. O Cabeçalho de Resposta Access-Control-Allow-Credentials é adicionado e configurado em true.
6. Se o servidor de aplicativos upstream não adicionou o Cabeçalho de Resposta Access-Control-Allow-Methods, o Cloud Gate construirá seu valor da seguinte forma:
  - Se o Cabeçalho Permitir Resposta estiver incluído na Resposta, o Cloud Gate usará seu valor.
  - Se o Cabeçalho da Solicitação Access-Control-Request-Method for encontrado na Solicitação, o Cloud Gate usará seu valor.
7. Se o servidor de aplicativos upstream não tiver adicionado o Cabeçalho de Resposta Access-Control-Allow-Headers, o Cloud Gate usará o valor do Cabeçalho de Solicitação Access-Control-Request-Headers na Solicitação, se ele estiver presente.
8. Se cloudGateCorsMaxAge for configurado com um valor maior que zero, o Cabeçalho de Resposta Access-Control-Max-Age será adicionado e configurado com o valor de idade máxima. Se o valor cloudGateCorsMaxAge for zero ou menor, nenhuma ação será tomada para o Cabeçalho de Resposta Access-Control-Max-Age.
9. O Cabeçalho de Resposta Access-Control-Expose-Headers foi removido. Não se aplica a respostas de pré-voo.
O Cloud Gate retorna sua Resposta.

Documentação do Oracle Cloud Infrastructure