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.
Atualizado em 2023-05-11 GMT+08:00

CORS

O que é o CORS?

Por motivos de segurança, os navegadores restringem as solicitações de origem cruzada 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 requisiçã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.

Configurar o CORS

O CORS está desativado por padrão. Para habilitar 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 permitidos para acesso entre domínios, crie um plug-in CORS.

  • Solicitações CORS simples

    Ao criar uma API, ative o CORS na página de configuração da solicitação da API. Para obter mais informações, consulte Solicitação simples.

    Figura 2 CORS
  • Solicitações 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 página Set Basic Information, selecione None para ignorar a autenticação de segurança.
      Figura 3 Nenhuma autenticação
    2. Na página Define API Request, execute as seguintes configurações:
      • Protocol: o mesmo protocolo usado pela API com o CORS ativado.
      • Path: insira uma barra (/).
      • Method: selecione OPTIONS.
      • CORS: ativado.
      Figura 4 Definição da solicitação da API
    3. Selecione o tipo de back-end Mock.
      Figura 5 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 habilitado e a resposta do back-end não contiver um cabeçalho 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 Origem:

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 Origem:

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 do 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 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 Configurar o CORS e crie outra API que será acessada usando o método OPTIONS.

Se você usar o plug-in 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:

  • API Group: o mesmo grupo ao qual a API com CORS habilitado pertence.
  • 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.
  • 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.
  • Method: selecione OPTIONS.
  • CORS: ativado.

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 comprovaçã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"}