Object Storage Service:CORS

Carregar recursos de site estático

O site em https://www.example.com precisa carregar imagens, CSS e arquivos JavaScript do OSS.

Fazer upload de arquivos diretamente do frontend

Os usuários fazem upload de avatares, documentos e outros arquivos para o OSS a partir da página da web em https://app.example.com.

Suporte para múltiplos ambientes

Múltiplos subdomínios para desenvolvimento, testes e produção, como dev.example.com e app.example.com, precisam acessar os mesmos recursos do OSS.

Fazer chamadas no estilo de API com autenticação

O aplicativo frontend em https://api.example.com precisa incluir cabeçalhos personalizados, como Authorization, para acessar recursos protegidos do OSS.

Requisições simples

As requisições simples podem ser enviadas diretamente e são processadas da seguinte forma:

1. O navegador adiciona o cabeçalho Origin à requisição. O cabeçalho contém a origem do recurso, por exemplo, Origin: https://www.example.com.

2. O OSS compara o método HTTP da requisição e o valor do cabeçalho Origin com a configuração CORS do bucket de destino. Se houver correspondência, o OSS inclui o cabeçalho Access-Control-Allow-Origin na resposta.

3. O navegador recebe a resposta e verifica se o valor de Access-Control-Allow-Origin corresponde ao domínio da requisição original. Em caso de correspondência, a requisição é bem-sucedida; caso contrário, ela falha.

Requisições de preflight

Uma requisição de preflight primeiro verifica se o servidor permite a requisição e é processada da seguinte forma:

1. O navegador envia uma requisição OPTIONS que inclui o método (Access-Control-Request-Method) e os cabeçalhos (Access-Control-Request-Headers) da requisição principal.

2. O OSS usa a configuração CORS para verificar se o método e os cabeçalhos da requisição são permitidos. Se algum método ou valor de cabeçalho na requisição de preflight não estiver no conjunto de métodos e cabeçalhos permitidos do recurso de destino, a requisição falha e a requisição principal não é enviada.

3. Após o sucesso do preflight, o navegador executa o mesmo processo de uma requisição simples.

Melhores práticas de segurança

• Configure origens precisas: A menos que o bucket seja totalmente público, não defina a origem como *. Especifique os domínios do site com precisão.

• Restrinja os métodos permitidos: Exponha apenas os métodos HTTP exigidos pelo seu aplicativo. Para cenários de somente leitura, configure apenas GET e HEAD.

• Liste explicitamente os cabeçalhos permitidos: Siga o princípio do menor privilégio. Liste explicitamente os cabeçalhos de requisição necessários sempre que possível e evite usar *.

Melhores práticas de desempenho

• Otimize o cache de preflight: Defina uma duração de cache razoável, como 86400 segundos, para reduzir as requisições de preflight, a latência e os custos de requisição.

• Avalie o efeito do Vary: Origin: A ativação desta opção evita a poluição do cache, mas pode reduzir a taxa de acertos do cache do CDN e aumentar os custos de tráfego de volta à origem. Ative-a apenas para múltiplas origens ou caracteres curinga.

Uso com CDN

Se um bucket tem a aceleração de CDN ativada e você o acessar por meio de um nome de domínio acelerado, as requisições cross-origin chegam primeiro a um ponto de presença do CDN. Configure o CORS de uma das seguintes maneiras:

• Configure o CORS no CDN: Configure as regras CORS no console do CDN para que o CDN retorne diretamente os cabeçalhos CORS. Para mais informações, consulte Configure cross-origin resource sharing.

• Repasse os cabeçalhos CORS da origem: O CDN repassa os cabeçalhos CORS retornados pelo OSS. Nesse caso, configure as regras CORS no OSS.

As configurações de CORS no OSS entram em vigor apenas quando as requisições acessam diretamente o nome de domínio de origem do OSS ou quando o CDN está configurado para repassar os cabeçalhos de resposta da origem.

Por que ocorre o erro “No 'Access-Control-Allow-Origin' header is present on the requested resource”?

Este erro geralmente ocorre porque o navegador armazenou em cache uma resposta antiga sem um cabeçalho CORS, ou porque as regras CORS estão configuradas de modo que nenhuma corresponda à requisição. Solucione o problema da seguinte forma:

1. Limpe o cache do navegador e teste novamente.

2. Verifique se a origem e os métodos permitidos da regra CORS correspondem à requisição real.

3. Crie temporariamente uma regra CORS permissiva para solucionar problemas: defina a origem como *, selecione todos os métodos permitidos, defina os cabeçalhos permitidos como *, defina os cabeçalhos expostos como ETag e x-oss-request-id, defina a duração do cache como 0 e selecione Vary: Origin.

4. Se o problema persistir, execute o seguinte comando em um servidor para visualizar os cabeçalhos da requisição cross-origin:

   curl -v -H 'Origin: <origin-address>' '<OSS-resource-URL>' -o output.txt

   Solucione o problema de acordo com a saída:

   

   • Se a resposta contiver um cabeçalho cross-origin correspondente à configuração, o cache do navegador pode ser a causa. Pressione Ctrl+F5 para limpar o cache do navegador ou defina a duração do cache como 0.

   • Se a resposta contiver dois cabeçalhos cross-origin ou um cabeçalho que não corresponda à configuração, o OSS pode estar acelerado pelo CDN.

     • Acesse o CDN console e desative temporariamente a aceleração do CDN para confirmar que não há problemas de cross-origin.

     • Após a confirmação, configure um cabeçalho de resposta personalizado em Cache > Modify Outgoing Response Header para o nome de domínio acelerado pelo CDN.

5. Se o problema persistir, consulte Common errors and solutions for OSS Cross-Origin Resource Sharing (CORS) para obter mais soluções.

Por que ocorre o erro “The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin”?

O servidor retornou o cabeçalho Access-Control-Allow-Origin, mas seu valor não corresponde ao Origin da requisição atual. Geralmente, isso indica um problema de cache: quando múltiplos domínios de sites acessam o OSS, o navegador ou o CDN podem reter a permissão de acesso para outro site.

Solução: Ative o Vary: Origin na regra CORS ou limpe o cache do navegador e acesse o recurso novamente.

Por que ocorre o erro “The value of the 'Access-Control-Allow-Origin' header must not be the wildcard '*' when credentials mode is 'include'”?

O aplicativo frontend envia uma requisição com credenciais (Access-Control-Allow-Credentials é True), mas a origem está configurada como o caractere curinga *. Por motivos de segurança, os navegadores não permitem origens curinga nesse caso.

Solução:

• Se as Credentials precisarem permanecer na requisição, altere a origem de * para um domínio específico, como https://example.com, e certifique-se de que Access-Control-Allow-Credentials esteja definido como true no servidor.

• Se as Credentials não forem necessárias, defina xhr.withCredentials como false no código do frontend e certifique-se de que Access-Control-Allow-Credentials esteja definido como false ou não seja retornado pelo servidor.

Por que o Access-Control-Allow-Origin no nível de objeto não entra em vigor?

O Access-Control-Allow-Origin no nível de objeto entra em vigor apenas quando nenhuma regra CORS no nível de bucket estiver configurada. Se as regras CORS no nível de bucket estiverem configuradas, o Access-Control-Allow-Origin no nível de objeto será ignorado, independentemente de a requisição corresponder ou não às regras.

Como melhorar o carregamento cross-origin lento a partir do OSS?

A velocidade de carregamento das requisições cross-origin depende do caminho físico de rede entre o cliente e o bucket do OSS, e não do CORS em si. O acesso de longa distância pode ocorrer quando o cliente está em China (Hong Kong) e o bucket está na China continental. Use OSS transfer acceleration para acessar o bucket.