Usando a CDN do Azure com CORS
Importante
O Azure CDN Standard da Microsoft (clássico) será desativado em 30 de setembro de 2027. Para evitar qualquer interrupção do serviço, é importante migrar o Azure CDN Standard dos perfis Microsoft (clássicos) para o Azure Front Door Standard ou Premium até 30 de setembro de 2027. Para obter mais informações, consulte Azure CDN Standard da aposentadoria (clássica) da Microsoft.
A CDN do Azure de Edgio será aposentada em 15 de janeiro de 2025. Você deve migrar sua carga de trabalho para o Azure Front Door antes dessa data para evitar a interrupção do serviço. Para obter mais informações, consulte CDN do Azure das Perguntas frequentes sobre aposentadoria do Edgio.
O que é o CORS?
CORS (cross-origin resource sharing) é um recurso HTTP que permite que um aplicativo Web executado em um domínio acesse recursos em outro domínio. Para reduzir a possibilidade de ataques de script entre sites, todos os navegadores da Web modernos implementam uma restrição de segurança conhecida como política de mesma origem. Essa restrição impede que uma página da Web chame APIs em um domínio diferente. O CORS fornece uma maneira segura de permitir que uma origem (o domínio de origem) chame APIs em outra origem.
Como funciona
Existem dois tipos de pedidos CORS, pedidos simples e pedidos complexos.
Para pedidos simples:
O navegador envia a solicitação CORS com um cabeçalho de solicitação HTTP Origin extra. O valor do cabeçalho da solicitação é a origem que serviu a página pai, que é definida como a combinação de protocolo, domínio e porta. Quando uma página de tenta acessar os dados de um usuário na origem do fabrikam.com, o cabeçalho da HTTPS://www.contoso.com solicitação a seguir é enviado para fabrikam.com:
Origin: https://www.contoso.comO servidor pode responder com qualquer um dos seguintes cabeçalhos:
Um cabeçalho Access-Control-Allow-Origin em sua resposta indicando qual site de origem é permitido. Por exemplo:
Access-Control-Allow-Origin: https://www.contoso.comUm código de erro HTTP, como 403, se o servidor não permitir a solicitação de origem cruzada depois de verificar o cabeçalho Origin
Um cabeçalho Access-Control-Allow-Origin com um curinga que permite todas as origens:
Access-Control-Allow-Origin: *
Para pedidos complexos:
Uma solicitação complexa é uma solicitação CORS em que o navegador é obrigado a enviar uma solicitação de comprovação (ou seja, uma sonda preliminar) antes de enviar a solicitação CORS real. A solicitação de comprovação pergunta à permissão do servidor se a solicitação CORS original pode continuar e é uma OPTIONS solicitação para a mesma URL.
Gorjeta
Para obter mais detalhes sobre fluxos CORS e armadilhas comuns, consulte o Guia de CORS para APIs REST.
Cenários curinga ou de origem única
O CORS na CDN do Azure funciona automaticamente sem configurações extras quando o cabeçalho Access-Control-Allow-Origin é definido como curinga (*) ou uma única origem. CDN armazenam em cache a primeira resposta e as solicitações subsequentes usam o mesmo cabeçalho.
Se as solicitações já tiverem sido feitas à CDN antes de o CORS ser definido na sua origem, você precisará limpar o conteúdo do seu conteúdo de ponto de extremidade para recarregar o conteúdo com o cabeçalho Access-Control-Allow-Origin .
Vários cenários de origem
Se você precisar permitir que uma lista específica de origens seja permitida para o CORS, as coisas ficam um pouco mais complicadas. O problema ocorre quando a CDN armazena em cache o cabeçalho Access-Control-Allow-Origin para a primeira origem CORS. Quando uma origem CORS diferente faz uma solicitação subsequente, a CDN serve o cabeçalho Access-Control-Allow-Origin armazenado em cache, que não corresponde. Há várias maneiras de corrigir esse problema.
Perfis padrão da CDN do Azure
Na CDN Standard do Azure da Microsoft, você pode criar uma regra no mecanismo de regras padrão para verificar o cabeçalho Origin na solicitação. Se for uma origem válida, sua regra define o cabeçalho Access-Control-Allow-Origin com o valor desejado. Nesse caso, o cabeçalho Access-Control-Allow-Origin do servidor de origem do arquivo é ignorado e o mecanismo de regras da CDN gerencia completamente as origens CORS permitidas.
Gorjeta
Você pode adicionar ações adicionais à regra para modificar cabeçalhos de resposta adicionais, como Access-Control-Allow-Methods.
Azure CDN Premium de Edgio
Usando o mecanismo de regras Edgio Premium, você precisa criar uma regra para verificar o cabeçalho Origin na solicitação. Se for uma origem válida, sua regra define o cabeçalho Access-Control-Allow-Origin com a origem fornecida na solicitação. Se a origem especificada no cabeçalho Origin não for permitida, sua regra deverá omitir o cabeçalho Access-Control-Allow-Origin , o que faz com que o navegador rejeite a solicitação.
Há duas maneiras de resolver esse problema com o mecanismo de regras Premium. Em ambos os casos, o cabeçalho Access-Control-Allow-Origin do servidor de origem do arquivo é ignorado e o mecanismo de regras da CDN gerencia completamente as origens CORS permitidas.
Uma expressão regular com todas as origens válidas
Nesse caso, você cria uma expressão regular que inclui todas as origens que deseja permitir:
https?:\/\/(www\.contoso\.com|contoso\.com|www\.microsoft\.com|microsoft.com\.com)$
Gorjeta
A CDN Premium do Azure da Edgio usa expressões regulares compatíveis com Perl como seu mecanismo para expressões regulares. Você pode usar uma ferramenta como Expressões Regulares 101 para validar sua expressão regular. Observe que o caractere "/" é válido em expressões regulares e não precisa ser escapado, no entanto, escapar desse caractere é considerado uma prática recomendada e é esperado por alguns validadores de regex.
Se a expressão regular corresponder, sua regra substituirá o cabeçalho Access-Control-Allow-Origin (se houver) da origem pela origem que enviou a solicitação. Você também pode adicionar cabeçalhos CORS extras, como Access-Control-Allow-Methods.
Regra de cabeçalho de solicitação para cada origem.
Em vez de expressões regulares, você pode criar uma regra separada para cada origem que deseja permitir usando a condição de correspondência Curinga de Cabeçalho de Solicitação. Tal como acontece com o método de expressão regular, o mecanismo de regras sozinho define os cabeçalhos CORS.
Gorjeta
No exemplo, o uso do caractere curinga * diz ao mecanismo de regras para corresponder a HTTP e HTTPS.