Exemplos de configuração de CORS

Vista geral Configuração

Esta página mostra exemplos de configurações para a partilha de recursos de origem cruzada (CORS).

Quando define uma configuração de CORS num contentor, permite interações entre recursos de origens diferentes, algo que é normalmente proibido para evitar comportamentos maliciosos. Para saber como estruturar um pedido que define ou edita uma configuração CORS num contentor, consulte as instruções em Usar CORS.

Tenha em atenção os seguintes recursos adicionais:

Configuração básica de CORS

Suponhamos que tem um Website dinâmico ao qual os utilizadores podem aceder em your-example-website.appspot.com. Tem um ficheiro de imagem alojado num contentor do Cloud Storage com o nome your-example-bucket. Quer usar a imagem no seu Website, pelo que tem de aplicar uma configuração CORS em your-example-bucket que permita aos navegadores dos seus utilizadores pedir recursos do contentor. Com base na seguinte configuração, os pedidos de pré-voo são válidos durante 1 hora e os pedidos bem-sucedidos do navegador devolvem o Content-Type do recurso na resposta.

API JSON

{
  "cors": [
    {
      "origin": ["https://your-example-website.appspot.com"],
      "method": ["GET"],
      "responseHeader": ["Content-Type"],
      "maxAgeSeconds": 3600
    }
  ]
}

API XML

<?xml version="1.0" encoding="UTF-8"?>
<CorsConfig>
  <Cors>
    <Origins>
      <Origin>https://your-example-website.appspot.com</Origin>
    </Origins>
    <Methods>
      <Method>GET</Method>
    </Methods>
    <ResponseHeaders>
      <ResponseHeader>Content-Type</ResponseHeader>
    </ResponseHeaders>
    <MaxAgeSec>3600</MaxAgeSec>
  </Cors>
</CorsConfig>

Carregamentos diretos de ficheiros (para aplicações de página única)

Use esta configuração quando a sua aplicação de front-end precisar de carregar ficheiros diretamente para um contentor, o que requer uma operação PUT. Esta é uma necessidade comum para aplicações de página única, em que a lógica da aplicação reside no navegador do utilizador em vez de num servidor de back-end.

Tenha em atenção que os pedidos PUT acionam sempre uma verificação prévia.

API JSON

{
 "cors": [
    {
        "origin": ["https://www.example-website.appspot.com"],
        "method": ["PUT", "POST", "OPTIONS"],
        "responseHeader": ["Content-Type", "x-goog-resumable"],
        "maxAgeSeconds": 3600
      }
  ]
}

API XML

<?xml version="1.0" encoding="UTF-8"?>
<CorsConfig>
  <Cors>
    <Origins>
      <Origin>https://your-example-website.appspot.com</Origin>
    </Origins>
    <Methods>
      <Method>PUT</Method>
      <Method>POST</Method>
      <Method>OPTIONS</Method>
    </Methods>
    <ResponseHeaders>
      <ResponseHeader>Content-Type</ResponseHeader>
      <ResponseHeader>x-goog-resumable</ResponseHeader>
    </ResponseHeaders>
    <MaxAgeSec>3600</MaxAgeSec>
  </Cors>
</CorsConfig>

Exemplo de código do lado do cliente

JavaScript

// Uploading a file using a Signed URL or direct PUT
await fetch(gcsSignedUrl, {
  method: 'PUT',
  body: fileBlob,
  headers: {
    'Content-Type': 'application/pdf'
  }
});

Acesso aos dados autenticado

Use esta configuração se a sua aplicação enviar um token de portador ou um Google cabeçalho de identidade para aceder a objetos protegidos (não públicos).

API JSON

{
 "cors": [
    {
        "origin": ["https://www.example-secure-app.appspot.com"],
        "method": ["GET", "HEAD"],
        "responseHeader": ["Authorization", "Content-Type"],
        "maxAgeSeconds": 3600
      }
  ]
}

API XML

<?xml version="1.0" encoding="UTF-8"?>
<CorsConfig>
  <Cors>
    <Origins>
      <Origin>https://www.example-secure-app.appspot.com</Origin>
    </Origins>
    <Methods>
      <Method>GET</Method>
      <Method>HEAD</Method>
    </Methods>
    <ResponseHeaders>
      <ResponseHeader>Authorization</ResponseHeader>
      <ResponseHeader>Content-Type</ResponseHeader>
    </ResponseHeaders>
    <MaxAgeSec>3600</MaxAgeSec>
  </Cors>
</CorsConfig>

Permitir o acesso a vários subdomínios correspondentes

Use esta configuração se tiver vários ambientes de desenvolvimento ou de teste que precisam de acesso ao mesmo contentor. A utilização do caráter universal * quando especifica um subdomínio permite-lhe fazer a correspondência de vários subdomínios. Por exemplo, pode usar *.example.com para fazer a correspondência com test.example.com e prod.example.com.

API JSON

{
 "cors": [
    {
        "origin": ["https://*.example.com"],
        "method": ["GET", "POST", "OPTIONS"],
        "responseHeader": ["Content-Type", "x-goog-resumable"],
        "maxAgeSeconds": 3600
      }
  ]
}

API XML

<?xml version="1.0" encoding="UTF-8"?>
<CorsConfig>
  <Cors>
    <Origins>
      <Origin>https://*.example.com</Origin>
    </Origins>
    <Methods>
      <Method>GET</Method>
      <Method>POST</Method>
      <Method>OPTIONS</Method>
    </Methods>
    <ResponseHeaders>
      <ResponseHeader>Content-Type</ResponseHeader>
      <ResponseHeader>x-goog-resumable</ResponseHeader>
    </ResponseHeaders>
    <MaxAgeSec>3600</MaxAgeSec>
  </Cors>
</CorsConfig>

Permitir o acesso para qualquer origem

Use esta configuração para dados públicos em que não é necessária restrição. Especificar o caráter universal * como a origem permite pedidos de qualquer origem. Tenha em atenção que, com esta configuração, os pedidos ao contentor vão falhar se o cliente definir credentials: include no respetivo pedido.

API JSON

{
 "cors": [
    {
        "origin": ["*"],
        "method": ["GET"],
        "responseHeader": ["Content-Type"],
        "maxAgeSeconds": 1800
      }
  ]
}

API XML

<?xml version="1.0" encoding="UTF-8"?>
<CorsConfig>
  <Cors>
    <Origins>
      <Origin>*</Origin>
    </Origins>
    <Methods>
      <Method>GET</Method>
    </Methods>
    <ResponseHeaders>
      <ResponseHeader>Content-Type</ResponseHeader>
    </ResponseHeaders>
    <MaxAgeSec>1800</MaxAgeSec>
  </Cors>
</CorsConfig>

Estrutura de configuração do CORS para a CLI gcloud

O comando gcloud storage buckets update --cors-file espera um ficheiro que contenha apenas a lista de regras CORS. Quando especificar uma configuração de CORS a ser definida através da Google Cloud CLI, remova o wrapper de nível superior do ficheiro JSON."cors":

Por exemplo, este comando da CLI gcloud define uma configuração CORS num contentor:

gcloud storage buckets update gs://example_bucket --cors-file=example_cors_file.json

Esta é uma configuração de exemplo para o example_cors_file.json que usa a estrutura correta para o comando gcloud storage buckets update --cors-file.

[
    {
      "origin": ["https://your-example-website.appspot.com"],
      "method": ["GET"],
      "responseHeader": ["Content-Type"],
      "maxAgeSeconds": 3600
    }
]

O que se segue?