# Cabeçalho HTTP CORS

CORS significa *Cross-Origin Resource Sharing*. É um mecanismo baseado em cabeçalho HTTP que permite a um servidor especificar origens diferentes da sua, como domínio, *scheme* ou *port*, a partir da qual um navegador deve permitir o carregamento de recursos.

Na Digibee Integration Platform, a política Cabeçalho HTTP CORS permite especificar cabeçalhos para verificar o recurso de origem cruzada com o servidor que o hospeda para ver se a solicitação é permitida. Você também pode definir diferentes pares de chave-valor para cabeçalhos em produção e outros ambientes.

<figure><img src="https://content.gitbook.com/content/cO0A6g1dOsu8BiHYqO67/blobs/j9DoRl38rrSNLiMY8MBT/cabe%C3%A7alho-http-cors-vis%C3%A3o-geral.png" alt=""><figcaption></figcaption></figure>

## Como configurar uma política Cabeçalho HTTP CORS

Siga estas etapas para configurar uma política Cabeçalho HTTP CORS:

1. Na página inicial da plataforma, clique em **Administração** no canto superior direito.
2. Clique em **Políticas**.
3. Clique na aba **Transformação**.
4. Abra a política **Cabeçalho HTTP CORS**. Você verá uma configuração diferente para cada ambiente.
5. Ative a opção **Não substituir a configuração do cabeçalho do pipeline pela nova configuração a seguir** se você não quiser substituir os valores dos cabeçalhos configurados nos *pipelines* pelos valores dos cabeçalhos da política. Se você mantiver esta opção desativada, os valores serão substituídos.

{% hint style="warning" %}
Os cabeçalhos só serão substituídos se tiverem a mesma **chave** tanto na política como no *pipeline*. Se eles não têm a mesma **chave**, os cabeçalhos do *pipeline* e da política serão somados na resposta.
{% endhint %}

6. Clique em **Add chave e valor** para adicionar um novo par de informações de chave-valor e insira os dados nos campos **key** e **value** correspondentes. A política Cabeçalho HTTP CORS valida cada par de chave-valor. Veja alguns exemplos de valores aceitos:&#x20;

* Access-Control-Allow-Origin: <http://example.com>, <https://sub.example.com>, \*
* Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD
* Access-Control-Allow-Headers: Content-Type, X-Requested-With, Authorization, Accept, Origin
* Access-Control-Allow-Credentials: true, false
* Access-Control-Expose-Headers: Content-Length, ETag, X-My-Custom-Header, X-Another-Custom-Header
* Access-Control-Max-Age: 600, 3600 (tempo em segundos)

7. Você pode excluir qualquer par de chave-valor clicando no ícone **X**.

{% hint style="info" %}
Pode levar alguns minutos para que os cabeçalhos sejam aplicados a todos os *pipelines*.
{% endhint %}

Você pode editar a política a qualquer momento seguindo as etapas descritas acima ou visualizar a configuração no modo somente leitura clicando no ícone de **olho**.

{% embed url="<https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MkqXsI0cPgzRnwxNhnH%2Fuploads%2F2Sv2HqNgw6F48OLTm1el%2Fconfigura%C3%A7%C3%A3o-http-cors.mp4?alt=media&token=94493a18-24d9-4876-9a37-d3cbddc83aa2>" %}

### Caso de uso: substituindo a configuração do cabeçalho do pipeline pela configuração da política

Suponha que você tenha uma API de pagamento usada por vários sites de comércio eletrônico. Esses sites estão hospedados em domínios diferentes e precisam se comunicar com sua API para processar transações de pagamento.

Sem cabeçalhos CORS, as solicitações feitas através do navegador dos clientes a partir de um domínio específico, por exemplo, “ecommerce1.com”, para sua API hospedada em outro domínio, por exemplo, “api.payments.com”, seria bloqueado devido à política de mesma origem. Esta política é um recurso de segurança do navegador que impede que um site faça solicitações para outro domínio. Para permitir que sites de comércio eletrônico acessem sua API de pagamento, você precisa adicionar cabeçalhos CORS à sua API.

Agora vamos imaginar duas situações:

#### Situação 1: você não deseja substituir a configuração do cabeçalho do pipeline

Nesta primeira situação, assumimos que seus *pipelines* devem aceitar apenas solicitações do domínio “ecommerce1.com”, mas se este domínio não estiver especificado no cabeçalho do *pipeline*, deverá aceitar qualquer domínio.

Neste caso, esta deve ser a configuração da política:

* Opção **Não substituir a configuração do cabeçalho do pipeline pela nova configuração a seguir** ativada.
* **Par de chave-valor:** `Access-Control-Allow-Origin: *`.

Isto significa que os valores configurados em cada *pipeline* substituirão os valores definidos na política. Então, se você criar um *pipeline* e adicionar o par chave-valor `Access-Control-Allow-Origin: ecommerce1.com`, o cabeçalho do *pipeline* terá precedência sobre o cabeçalho configurado na política.

No entanto, se você não adicionar um cabeçalho com a chave `Access-Control-Allow-Origin` com um domínio específico para o seu *pipeline*, qualquer domínio será aceito já que o cabeçalho `Access-Control-Allow-Origin: *` está configurado na política, que será considerada no lugar da configuração do *pipeline*.

#### Situação 2: você deseja substituir a configuração do cabeçalho do pipeline

Agora vamos supor que seus *pipelines* devem sempre aceitar solicitações de qualquer domínio, independentemente do *pipeline* ter um cabeçalho indicando que apenas um domínio específico deve fazer solicitações.

Neste caso, esta deve ser a configuração da política:

* Opção **Não substituir a configuração do cabeçalho do pipeline pela nova configuração a seguir** desativada.
* **Par de chave-valor:** `Access-Control-Allow-Origin: *`.

Isso significa que, independentemente de a configuração do *pipeline* conter o cabeçalho `Access-Control-Allow-Origin` configurado com um domínio específico, o cabeçalho `Access-Control-Allow-Origin: *` configurado na política é levado em consideração.