Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Central de ajuda/ API Gateway/ Guia de usuário/ Gerenciamento de API/ CORS
Atualizado em 2024-10-14 GMT+08:00
Ver PDF
Compartilhar

CORS

O que é o CORS?

Por motivos de segurança, os navegadores restringem as solicitações entre origens iniciadas a partir de scripts. Isso significa que uma aplicação Web só pode solicitar recursos de sua origem. O mecanismo CORS permite que os navegadores enviem XMLHttpRequest para servidores em outros domínios e solicitem acesso aos recursos lá.

Figura 1 Fluxo de processo do mecanismo CORS

Existem dois tipos de solicitações CORS:

  • Solicitações simples
    As solicitações simples devem atender às seguintes condições:
    1. O método de solicitação é HEAD, GET ou POST.
    2. O cabeçalho da solicitação contém apenas os seguintes campos:
      • Accept
      • Accept-Language
      • Content-Language
      • Last-Event-ID
      • Content-Type (application/x-www-form-urlencoded, multipart/form-data ou text/plain)

    No cabeçalho de uma solicitação simples, os navegadores adicionam automaticamente o campo Origin para especificar a origem (incluindo o protocolo, o domínio e a porta) da solicitação. Depois de receber tal solicitação, o servidor de destino determina se a solicitação é segura e pode ser aceita com base na origem. Se o servidor enviar uma resposta contendo o campo Access-Control-Allow-Origin, o servidor aceitará a solicitação.

  • Solicitações não tão simples

    Solicitações que não atendem às condições para solicitações simples são solicitações não tão simples.

    Antes de enviar uma solicitação não tão simples, os navegadores enviam uma solicitação de simulação HTTP ao servidor de destino para confirmar se a origem da página da Web está na lista de origem permitida e para confirmar quais métodos de solicitação HTTP e campos de cabeçalho podem ser usados. Se a solicitação de simulação for bem-sucedida, os navegadores enviam solicitações simples para o servidor.

Configuração de CORS

O CORS está desativado por padrão. Para ativar o CORS para uma API, execute as operações descritas nesta seção. Para personalizar cabeçalhos de solicitação, métodos de solicitação e origens permitidas para acesso entre domínios, crie uma política de plug-in de CORS consultando CORS.

  • Solicitações de CORS simples

    Ao criar uma API, habilite o CORS na área Security Configuration da página Create API. Para obter mais informações, consulte Solicitação simples.

  • Solicitações de CORS não tão simples

    Se sua API receberá solicitações não tão simples, crie outra API que será acessada usando o método OPTIONS no mesmo grupo da API de destino para receber solicitações de simulação.

    Siga este procedimento para definir a API de solicitação de simulação. Para obter mais informações, consulte Solicitações não tão simples.

    1. Na área Frontend Definition, defina os seguintes parâmetros:
      • Method: selecione OPTIONS.
      • Protocol: o mesmo protocolo usado pela API com o CORS ativado.
      • Path: insira uma barra (/).
      Figura 2 Definição da solicitação de API
    2. Na área Security Configuration, selecione None e habilite CORS.
      Figura 3 Nenhuma autenticação
    3. Selecione o tipo de back-end Mock.
      Figura 4 Serviço de back-end Mock

Solicitação simples

Ao criar uma API que receberá solicitações simples, ative o CORS para a API.

Cenário 1: se o CORS estiver ativado e a resposta do back-end não contiver um cabeçalho de CORS, o APIG tratará solicitações de qualquer domínio e retornará o cabeçalho Access-Control-Allow-Origin. Por exemplo:

Solicitação enviada por um navegador e contendo o campo de cabeçalho Origin:

GET /simple HTTP/1.1
Host: www.test.com
Origin: http://www.cors.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Accept: application/json
Date: Tue, 15 Jan 2019 01:25:52 GMT

Origin: este campo é necessário para especificar a origem (http://www.cors.com neste exemplo) da solicitação. O APIG e o serviço de back-end determinam, com base na origem, se a solicitação é segura e pode ser aceita.

Resposta enviada pelo serviço de back-end:

HTTP/1.1 200 OK
Date: Tue, 15 Jan 2019 01:25:52 GMT
Content-Type: application/json
Content-Length: 16
Server: api-gateway

{"status":"200"}

Resposta enviada pelo APIG:

HTTP/1.1 200 OK
Date: Tue, 15 Jan 2019 01:25:52 GMT
Content-Type: application/json
Content-Length: 16
Server: api-gateway
X-Request-Id: 454d689fa69847610b3ca486458fb08b
Access-Control-Allow-Origin: *

{"status":"200"}

Access-Control-Allow-Origin: este campo é obrigatório. O asterisco (*) significa que o APIG lida com solicitações enviadas de qualquer domínio.

Cenário 2: se o CORS estiver habilitado e a resposta do back-end contiver um cabeçalho CORS, o cabeçalho substituirá o adicionado pelo APIG. As seguintes mensagens são usadas como exemplos:

Solicitação enviada por um navegador e contendo o campo de cabeçalho Origin:

GET /simple HTTP/1.1
Host: www.test.com
Origin: http://www.cors.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Accept: application/json
Date: Tue, 15 Jan 2019 01:25:52 GMT

Origin: este campo é necessário para especificar a origem (http://www.cors.com neste exemplo) da solicitação. O APIG e o serviço de back-end determinam, com base na origem, se a solicitação é segura e pode ser aceita.

Resposta enviada pelo serviço de back-end:

HTTP/1.1 200 OK
Date: Tue, 15 Jan 2019 01:25:52 GMT
Content-Type: application/json
Content-Length: 16
Server: api-gateway
Access-Control-Allow-Origin: http://www.cors.com

{"status":"200"}

Access-Control-Allow-Origin: indica que o serviço de back-end aceita solicitações enviadas de http://www.cors.com.

Resposta enviada pelo APIG:

HTTP/1.1 200 OK
Date: Tue, 15 Jan 2019 01:25:52 GMT
Content-Type: application/json
Content-Length: 16
Server: api-gateway
X-Request-Id: 454d689fa69847610b3ca486458fb08b
Access-Control-Allow-Origin: http://www.cors.com

{"status":"200"}

O cabeçalho de CORS na resposta de back-end substitui o da resposta do APIG.

Solicitações não tão simples

Ao criar uma API que receberá solicitações não tão simples, habilite o CORS para a API seguindo as instruções em Configuração de CORS e crie outra API que será acessada usando o método OPTIONS.

Se você usar a política de plug-in de CORS para uma API, não precisará criar outra API que use o método OPTIONS.

Os parâmetros de solicitação de uma API acessada usando o método OPTIONS devem ser definidos da seguinte forma:

  • Group: o mesmo grupo ao qual a API com CORS ativado pertence.
  • Method: selecione OPTIONS.
  • Protocol: o mesmo protocolo usado pela API com o CORS ativado.
  • Path: insira uma barra (/) ou selecione o caminho que foi definido ou corresponda à API com CORS ativado.
  • Security Authentication: selecione None. Nenhuma autenticação é necessária para solicitações recebidas pela nova API, independentemente do modo de autenticação de segurança selecionado.
  • CORS: ative esta opção.

A seguir estão exemplos de solicitações e respostas enviadas para ou de um back-end mock.

Solicitação enviada de um navegador para uma API que é acessada usando o método OPTIONS:

OPTIONS /HTTP/1.1
User-Agent: curl/7.29.0
Host: localhost
Accept: */*
Origin: http://www.cors.com
Access-Control-Request-Method: PUT 
Access-Control-Request-Headers: X-Sdk-Date
  • Origin: esse campo é necessário para especificar a origem da qual a solicitação foi enviada.
  • Access-Control-Request-Method: este campo é necessário para especificar os métodos HTTP a serem usados pelas solicitações simples subsequentes.
  • Access-Control-Request-Headers: esse campo é opcional e usado para especificar os campos de cabeçalho adicionais nas solicitações simples subsequentes.

Resposta enviada pelo back-end: nenhuma

Resposta enviada pelo APIG:

HTTP/1.1 200 OK
Date: Tue, 15 Jan 2019 02:38:48 GMT
Content-Type: application/json
Content-Length: 1036
Server: api-gateway
X-Request-Id: c9b8926888c356d6a9581c5c10bb4d11
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Stage,X-Sdk-Date,X-Sdk-Nonce,X-Proxy-Signed-Headers,X-Sdk-Content-Sha256,X-Forwarded-For,Authorization,Content-Type,Accept,Accept-Ranges,Cache-Control,Range
Access-Control-Expose-Headers: X-Request-Id,X-Apig-Latency,X-Apig-Upstream-Latency,X-Apig-RateLimit-Api,X-Apig-RateLimit-User,X-Apig-RateLimit-App,X-Apig-RateLimit-Ip,X-Apig-RateLimit-Api-Allenv
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,HEAD,OPTIONS,PATCH
Access-Control-Max-Age: 172800
  • Access-Control-Allow-Origin: este campo é obrigatório. O asterisco (*) significa que o APIG lida com solicitações enviadas de qualquer domínio.
  • Access-Control-Allow-Headers: este campo é obrigatório se estiver contido na solicitação. Indica todos os campos de cabeçalho que podem ser usados durante o acesso entre origens.
  • Access-Control-Expose-Headers: estes são os campos de cabeçalho de resposta que podem ser visualizados durante o acesso entre regiões.
  • Access-Control-Allow-Methods: este campo é necessário para especificar quais métodos de solicitação HTTP o APIG suporta.
  • Access-Control-Max-Age: este campo é opcional e usado para especificar o período de tempo (em segundos) durante o qual o resultado da simulação permanece válido. Não serão enviadas mais solicitações de simulação dentro do período especificado.

Solicitação enviada por um navegador e contendo o campo de cabeçalho Origin:

PUT /simple HTTP/1.1
Host: www.test.com
Origin: http://www.cors.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Accept: application/json
Date: Tue, 15 Jan 2019 01:25:52 GMT

Resposta enviada pelo back-end:

HTTP/1.1 200 OK
Date: Tue, 15 Jan 2019 01:25:52 GMT
Content-Type: application/json
Content-Length: 16
Server: api-gateway

{"status":"200"}

Resposta enviada pelo APIG:

HTTP/1.1 200 OK
Date: Tue, 15 Jan 2019 01:25:52 GMT
Content-Type: application/json
Content-Length: 16
Server: api-gateway
X-Request-Id: 454d689fa69847610b3ca486458fb08b
Access-Control-Allow-Origin: *

{"status":"200"}

Tópico principal: Gerenciamento de API