Configure CORS for CDN with HTTP response headers - CDN: Central de Documentação do Alibaba Cloud

Após adicionar seu serviço ao Alibaba Cloud CDN, ative o acesso de origem cruzada configurando cabeçalhos de resposta HTTP nos POPs.

O que é compartilhamento de recursos de origem cruzada?

O compartilhamento de recursos de origem cruzada (CORS) é um mecanismo padrão que permite a uma página da web acessar recursos de uma origem diferente (domínio, protocolo ou porta) da sua própria. Ele oferece uma maneira segura de habilitar transferências de dados entre origens distintas. Para mais informações, consulte Cross-Origin Resource Sharing (CORS).

Nota

P: O que acontece se o CORS não estiver ativado no CDN por padrão?

Por padrão, o CDN não ativa o compartilhamento de recursos de origem cruzada (CORS). Sem essa configuração, os navegadores aplicam a política de mesma origem e bloqueiam solicitações de origem cruzada, impedindo outros sites de carregar seus recursos.

Por que configurar o compartilhamento de recursos de origem cruzada?

Devido a restrições de segurança, os navegadores geralmente seguem a política de mesma origem, que limita as solicitações para carregar e acessar recursos de domínios, subdomínios, protocolos ou portas diferentes. Por exemplo, example.com não consegue acessar recursos em example.org. Ao configurar o compartilhamento de recursos de origem cruzada (CORS), você define os cabeçalhos de resposta relevantes no servidor CDNDCDN. Se uma solicitação incluir cabeçalhos que atendam às regras permitidas, o servidor retorna os cabeçalhos de resposta HTTP correspondentes, permitindo o carregamento e o acesso aos recursos de origem cruzada.

Como funciona

CORS configurado no servidor de source

Com CORS configurado no CDN

Observações de uso

Se você usar um bucket do OSS como servidor de source, a configuração de CORS no console CDNDCDN substitui a configuração de CORS no console do OSS. Para mais informações sobre como configurar o CORS no console do OSS, consulte Definir regras de CORS.
Caso utilize um servidor local ou uma instância ECS como servidor de source, recomenda-se separar o conteúdo estático do dinâmico e usar o CDNDCDN para acelerar a entrega de arquivos estáticos. O recurso CORS configurado no console CDNDCDN aplica-se apenas a arquivos estáticos.

Ativar compartilhamento de recursos de origem cruzada

Faça login no CDN console.
No painel de navegação à esquerda, clique em Domain Names.
Na página Domains, localize o domínio que deseja gerenciar e clique em Actions na coluna Manage.

Clique em Cache, selecione a aba Modify Outgoing Response Header e defina as origens e métodos permitidos para solicitações de origem cruzada.

Definir a origem para solicitações de origem cruzada

Clique em Customize, configure os parâmetros conforme descrito na tabela a seguir e clique em OK.

Parâmetro	Descrição	Exemplo
Operation	Defina este parâmetro como Add para ativar o recurso de validação de CORS.	Add
Response Header	É necessário definir `Access-Control-Allow-Origin` para utilizar o recurso de validação de origem cruzada.	Access-Control-Allow-Origin
Header Value	Com a validação de CORS desativada: Especifique apenas um curinga ou uma única origem. Curinga ``: Permite que qualquer origem acesse o recurso. Origem única: Restringe o acesso aos recursos a uma origem específica (nome de domínio). Com a validação de CORS ativada:* Especifique um curinga, uma única origem, múltiplas origens ou um domínio com curinga. Curinga ``: Permite que qualquer origem acesse o recurso. Origem única: Restringe o acesso aos recursos a uma origem específica (nome de domínio). Múltiplas origens especificadas:* Configure várias origens específicas (nomes de domínio), separadas por vírgula `,`, para permitir que essas origens acessem o recurso. Domínio com curinga: Especifique um domínio com curinga para permitir o acesso de todas as origens que correspondam ao padrão.	`` `http://www.aliyun.com` `https://aliyun.com,http://www.aliyun.com` `http://.aliyun.com`
Allow Duplicates	Yes: Os cabeçalhos do servidor de source são preservados e o novo cabeçalho com nome idêntico também é adicionado à resposta. No: O novo cabeçalho substitui qualquer cabeçalho com nome idêntico proveniente do servidor de source. Importante As configurações Allow Duplicates e CORS Validation são mutuamente exclusivas. Se você definir Allow Duplicates como Yes, a validação de CORS será desativada.	No
CORS	O CORS só pode ser configurado quando Operation estiver definido como Add e Response Header estiver definido como "Access-Control-Allow-Origin". O CORS pode ser definido como Disable ou Enable. O valor padrão é Disable. Disable: Os POPs do CDN não validam o cabeçalho `Origin` nas solicitações recebidas e sempre retornam o valor configurado de `Access-Control-Allow-Origin`. Enable: Os POPs do CDN validam solicitações de origem cruzada com base nas seguintes regras e respondem com o valor de `Access-Control-Allow-Origin` adequadamente. Response Header: Se Response Header estiver definido como , o POP sempre retorna `Access-Control-Allow-Origin:`, independentemente de a solicitação do usuário conter um cabeçalho `Origin` ou qual seja seu valor. Response Header: Response Header está definido como uma ou mais origens específicas, separadas por vírgulas (`,`). Se o valor do cabeçalho `Origin` na solicitação do usuário corresponder exatamente a uma das origens configuradas, o POP responde com essa origem como o valor do cabeçalho `Access-Control-Allow-Origin`. Caso nenhuma correspondência seja encontrada, o POP não adiciona o cabeçalho CORS à resposta. Response Header: Se Response Header estiver definido como um domínio com curinga, o POP verifica se o cabeçalho `Origin` na solicitação corresponde ao padrão de curinga. Se você definir Enable como Header Value e o nome de domínio no campo Header Value contiver um hífen (`-`), será necessário escapá-lo substituindo `-` por `%-`. Exemplo: Valor original do cabeçalho: `http://doc.aliyun-example.com`. Valor do cabeçalho com escape: `http://doc.aliyun%-example.com`.	Enable

Definir os métodos para solicitações de origem cruzada

Clique em Customize, configure os parâmetros conforme descrito na tabela a seguir e clique em OK.

Parâmetro	Descrição	Exemplo
Operation	Defina este parâmetro como Add.	Add
Response Header	Deve ser definido como `Access-Control-Allow-Methods`	Access-Control-Allow-Methods
Header Value	Suporta os métodos de solicitação `GET, POST e PUT`. Caso precise adicionar `GET, POST e PUT` simultaneamente, separe-os com uma vírgula `,`.	`GET`
Allow Duplicates	Yes: Os cabeçalhos do servidor de source são preservados e o novo cabeçalho com nome idêntico também é adicionado à resposta. No: O novo cabeçalho substitui qualquer cabeçalho com nome idêntico proveniente do servidor de source.	No

Nota

P: Após adicionar um cabeçalho de resposta CORS, ele será aplicado a recursos estáticos previamente armazenados em cache?

Não. O CDN armazena em cache toda a resposta HTTP, incluindo os cabeçalhos. Para aplicar um novo cabeçalho CORS a conteúdo já armazenado em cache, limpe as URLs desses recursos. Caso contrário, os usuários continuarão recebendo a resposta desatualizada do cache.

Exemplos de configuração

Exemplo 1

Se o valor do cabeçalho de resposta para CORS estiver definido como uma ou mais origens específicas separadas por vírgulas (,):

Quando o valor do cabeçalho Origin na solicitação do usuário corresponder exatamente a uma das origens especificadas, o POP do CDNDCDN responderá com o cabeçalho CORS correspondente.
Se não houver correspondência exata, o cabeçalho CORS não será incluído na resposta.

No CDN/DCDN, defina: Access-Control-Allow-Origin: http://example.com,https://aliyundoc.com.

O cabeçalho Origin da solicitação do usuário é http://example.com, e o Ponto de Presença (POP) do CDNDCDN responde com Access-Control-Allow-Origin: http://example.com.
O cabeçalho Origin na solicitação do usuário é https://aliyundoc.com, e o nó do CDNDCDN responde com Access-Control-Allow-Origin: https://aliyundoc.com.
O nó do CDNDCDN não responderá a uma solicitação de usuário com o cabeçalho Origin http://aliyundoc.com (devido a incompatibilidade de protocolo: a solicitação do usuário usa HTTP, enquanto o CDNDCDN está configurado para HTTPS).
Caso o cabeçalho Origin de uma solicitação seja http://aliyun.com, o POP do CDNDCDN não responderá (incompatibilidade de domínio).

Exemplo 2

Se o valor do cabeçalho de resposta para CORS estiver definido como um domínio com curinga, o POP verifica se o valor de Origin no cabeçalho da solicitação corresponde ao padrão de curinga.

No CDN/DCDN, defina: Access-Control-Allow-Origin: http://*.aliyundoc.com.

A solicitação do usuário contém o cabeçalho Origin http://demo.aliyundoc.com, e o POP do CDNDCDN responde com Access-Control-Allow-Origin: http://demo.aliyundoc.com.
Se o cabeçalho Origin de uma solicitação for http://demo.example.com, o POP do CDNDCDN não responderá porque o nome de domínio não corresponde.
O nó do CDNDCDN não responde a uma solicitação de usuário com o cabeçalho Origin https://demo.aliyundoc.com porque a solicitação usa o protocolo HTTPS, mas o CDNDCDN está configurado com o protocolo HTTP.

Nota

P: Como posso usar curl para verificar se o cabeçalho Access-Control-Allow-Origin do CDN está funcionando?

Envie uma solicitação GET com um cabeçalho Origin usando curl -svo /dev/null e inspecione a saída detalhada em busca dos cabeçalhos de resposta. Se o cabeçalho Access-Control-Allow-Origin aparecer na resposta com o valor esperado (por exemplo, * ou seu domínio especificado), sua configuração de CORS está funcionando. Se o cabeçalho estiver ausente, revise suas regras personalizadas de cabeçalho de resposta no console do CDN e as configurações de CORS do seu servidor de source.

curl -svo /dev/null https://img.anleme.cc/agent/dl1.jpg -H 'origin:https://am.anleme.cc'

FAQ

Por que ainda ocorre um erro de origem cruzada após eu configurar o cabeçalho de resposta Access-Control-Allow-Origin, e o cabeçalho está ausente na resposta?

Nota

P: A configuração de CORS do CDN suporta múltiplos domínios com curinga separados por vírgulas?

Não. Quando a validação de CORS está ativada no CDN, você pode configurar apenas um único domínio com curinga. Alternativamente, liste vários domínios exatos (sem curinga) separados por vírgulas. Não é possível especificar uma lista separada por vírgulas de múltiplos domínios com curinga, como https://*.iflyvoice.cn,https://*.xxx.com.

Nota

P: Por que arquivos de fontes acessados por meio de um domínio acelerado por CDN acionam um problema de CORS, enquanto arquivos de vídeo não?

Esse comportamento é determinado pelo tipo de recurso e pela política de segurança do navegador. Por padrão, arquivos de vídeo (como MP4 ou WebM) carregados via tag <video> não estão sujeitos a restrições de CORS, a menos que o atributo crossorigin seja explicitamente adicionado. Em contraste, arquivos de fontes (como .ttf ou .woff) estão sempre sujeitos à validação obrigatória de CORS pelo navegador, independentemente de como são carregados. Portanto, mesmo que ambos os tipos de recursos estejam hospedados no mesmo domínio, as solicitações de fontes falharão sem uma política de CORS válida, enquanto as solicitações de vídeo geralmente têm sucesso. Essa diferença decorre das políticas de segurança padrão dos navegadores para diferentes tipos de conteúdo.

Nota

P: Como posso verificar se minha configuração de CORS do CDN está eficaz?

Utilize os métodos a seguir para verificação:

Teste novamente para ver se o erro de origem cruzada persiste.
Use o comando curl -svo /dev/null para enviar uma solicitação GET com um cabeçalho Origin específico e verifique os cabeçalhos de resposta na saída detalhada. Por exemplo:curl -svo /dev/null https://img.anleme.cc/agent/dl1.jpg -H 'origin:https://am.anleme.cc'
Forneça o domínio de teste ao suporte técnico para obter assistência.

Nota

P: Ao acelerar um bucket do OSS com o CDN, como posso repassar a configuração de CORS da source OSS?

Para habilitar o repasse da configuração de CORS de um servidor de source OSS, a solicitação inicial ao CDN deve incluir um cabeçalho Origin. Isso permite que o CDN busque na source e armazene em cache o cabeçalho de resposta Access-Control-Allow-Origin. No entanto, esse mecanismo de cache pode causar problemas de CORS para solicitações subsequentes que tenham um Origin diferente ou nenhum cabeçalho Origin. A melhor prática recomendada é configurar os cabeçalhos CORS diretamente no console do CDN usando o recurso Modify Outgoing Request Header em Cache Settings, em vez de depender do repasse.

Nota

P: Se vários domínios de CDN estiverem associados ao mesmo bucket do OSS, posso configurar a regra de CORS apenas uma vez no OSS e tê-la herdada automaticamente por todos os domínios de CDN?

Não. Como os POPs do CDN armazenam cabeçalhos de resposta em cache e esse comportamento é afetado pelo fato de a solicitação inicial conter ou não um cabeçalho Origin, depender de uma configuração de repasse do OSS pode causar erros intermitentes de CORS. A melhor prática é adicionar cabeçalhos CORS usando o recurso Modify Outgoing Request Header para garantir um comportamento correto e estável.