Resolução de problemas

Esta página descreve os métodos de resolução de problemas para erros comuns que pode encontrar ao usar o Cloud Storage.

Consulte o Trusted Cloud by S3NS Painel de controlo do estado do serviço para ver informações sobre incidentes que afetam Trusted Cloud by S3NS serviços como o Cloud Storage.

Registo de pedidos não processados

Quando usa ferramentas como gcloud ou as bibliotecas de cliente do Cloud Storage, grande parte das informações de pedido e resposta são processadas pela ferramenta. No entanto, por vezes, é útil ver detalhes para ajudar na resolução de problemas ou quando publica perguntas em fóruns como o Stack Overflow. Use as instruções seguintes para devolver os cabeçalhos de pedido e resposta da sua ferramenta:

gcloud storage ls gs://my-bucket/my-object --log-http --verbosity=debug

import logging
import http.client

logging.basicConfig(level=logging.DEBUG)
http.client.HTTPConnection.debuglevel=5

ruby
Google::Apis.logger.level = Logger::DEBUG

Adicionar cabeçalhos personalizados

A adição de cabeçalhos personalizados a pedidos é uma ferramenta comum para fins de depuração, como para ativar cabeçalhos de depuração ou para rastrear um pedido. O exemplo seguinte mostra como definir cabeçalhos de pedidos para diferentes ferramentas do Cloud Storage:

gcloud storage objects describe gs://my-bucket/my-object --additional-headers=HEADER_NAME=HEADER_VALUE

namespace gcs = google::cloud::storage;
gcs::Client client = ...;
client.AnyFunction(... args ..., gcs::CustomHeader("header-name", "value"));

using Google.Cloud.Storage.V1;

var client = StorageClient.Create();
client.Service.HttpClient.DefaultRequestHeaders.Add("custom-header", "custom-value");

var buckets = client.ListBuckets("my-project-id");
foreach (var bucket in buckets)

{
  Console.WriteLine(bucket.Name);
}

package main

import (
  "context"

  "cloud.google.com/go/storage"
  "github.com/googleapis/gax-go/v2/callctx"
)

func main() {
  ctx := context.Background()

  client, err := storage.NewClient(ctx)
  if err != nil {
    // Handle error.
  }
  ctx = callctx.SetHeaders(ctx, "X-Custom-Header", "value")

  // Use client as usual with the context and the additional headers will be sent.
  _, err = client.Bucket("my-bucket").Attrs(ctx)
  if err != nil {
    // Handle error.
  }
}

import com.google.api.gax.rpc.FixedHeaderProvider;
import com.google.api.gax.rpc.HeaderProvider;
import com.google.cloud.WriteChannel;
import com.google.cloud.storage.BlobInfo;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;

import java.io.IOException;
import java.nio.ByteBuffer;
import static java.nio.charset.StandardCharsets.UTF_8;

public class Example {

  public void main(String args[]) throws IOException {
    HeaderProvider headerProvider =
            FixedHeaderProvider.create("custom-header", "custom-value");
    Storage storage = StorageOptions.getDefaultInstance()
            .toBuilder()
            .setHeaderProvider(headerProvider)
            .build().getService();
    String bucketName = "example-bucket";
    String blobName = "test-custom-header";

    // Use client with custom header
    BlobInfo blob = BlobInfo.newBuilder(bucketName, blobName).build();
    byte[] stringBytes;
    try (WriteChannel writer = storage.writer(blob)) {
      stringBytes = "hello world".getBytes(UTF_8);
      writer.write(ByteBuffer.wrap(stringBytes));
    }
  }
}

const storage = new Storage();

storage.interceptors.push({
  request: requestConfig => {
    Object.assign(requestConfig.headers, {
      'X-Custom-Header': 'value',
      });
    return requestConfig;
  },
});

use Google\Cloud\Storage\StorageClient;

$client = new StorageClient([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bat'
       ]
   ]
]);

$bucket = $client->bucket('my-bucket');

$bucket->info([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bar'
       ]
   ]
]);

from google.cloud import storage

client = storage.Client(
    extra_headers={
        "x-custom-header": "value"
    }
)

require "google/cloud/storage"

storage = Google::Cloud::Storage.new

storage.add_custom_headers { 'X-Custom-Header'=> 'value' }

Aceder a contentores com uma configuração de CORS

Se tiver definido uma configuração de CORS no seu contentor e reparar que os pedidos recebidos de navegadores de clientes estão a falhar, experimente os seguintes passos de resolução de problemas:

1. Reveja a configuração de CORS no contentor de destino. Se existirem várias entradas de configuração de CORS, certifique-se de que os valores de pedido que usa para a resolução de problemas são mapeados para valores numa única entrada de configuração de CORS.

2. Quando testar a emissão de um pedido CORS, verifique se não está a fazer um pedido para o ponto final storage.cloud.google.com, que não permite pedidos CORS. Para mais informações sobre os pontos finais suportados para CORS, consulte o artigo Suporte de CORS do Cloud Storage.

3. Reveja um pedido e uma resposta através da ferramenta da sua escolha. Num navegador Chrome, pode usar as ferramentas para programadores padrão para ver estas informações:

   1. Clique no menu do Chrome (more_vert) na barra de ferramentas do navegador.
   2. Selecione Mais ferramentas > Ferramentas para programadores.
   3. Clique no separador Rede.
   4. A partir da sua aplicação ou linha de comandos, envie o pedido.
   5. No painel que apresenta a atividade de rede, localize o pedido.
   6. Na coluna Nome, clique no nome correspondente ao pedido.
   7. Clique no separador Cabeçalhos para ver os cabeçalhos de resposta ou no separador Resposta para ver o conteúdo da resposta.

   Se não vir um pedido e uma resposta, é possível que o seu navegador tenha colocado em cache uma tentativa anterior de pedido de pré-voo com falha. A limpeza da cache do navegador também deve limpar a cache de pré-voo. Se não for, defina o valor MaxAgeSec na configuração CORS para um valor inferior ao valor predefinido de 1800 (30 minutos), aguarde o tempo do MaxAgeSec antigo e, em seguida, tente o pedido novamente. Isto executa um novo pedido de verificação prévia, que obtém a nova configuração do CORS e limpa as entradas da cache. Depois de depurar o problema, aumente novamente o valor de MaxAgeSec para reduzir o tráfego de pré-lançamento para o seu contentor.

4. Certifique-se de que o pedido tem um cabeçalho Origin e que o valor do cabeçalho corresponde, pelo menos, a um dos valores Origins na configuração de CORS do contentor. Tenha em atenção que o esquema, o anfitrião e a porta dos valores têm de corresponder exatamente. Seguem-se alguns exemplos de correspondências aceitáveis:

   • http://origin.example.com corresponde a http://origin.example.com:80 (porque 80 é a porta HTTP predefinida), mas não corresponde a https://origin.example.com, http://origin.example.com:8080, http://origin.example.com:5151 nem http://sub.origin.example.com.

   • https://example.com:443 corresponde a https://example.com, mas não a http://example.com nem a http://example.com:443.

   • http://localhost:8080 só corresponde exatamente a http://localhost:8080 e não corresponde a http://localhost:5555 nem a http://localhost.example.com:8080.

5. Para pedidos simples, certifique-se de que o método HTTP do pedido corresponde a, pelo menos, um dos valores Methods na configuração de CORS do contentor. Para pedidos de pré-voo, certifique-se de que o método especificado em Access-Control-Request-Method corresponde, pelo menos, a um dos valores de Methods.

6. Para pedidos de verificação prévia, verifique se inclui um ou mais cabeçalhos Access-Control-Request-Header. Se for o caso, certifique-se de que cada valor Access-Control-Request-Header corresponde a um valor ResponseHeader na configuração CORS do contentor. Todos os cabeçalhos com nome no elemento Access-Control-Request-Header têm de estar na configuração CORS para que o pedido de verificação prévia seja bem-sucedido e inclua cabeçalhos CORS na resposta.

Códigos de erro

Seguem-se códigos de estado HTTP comuns que pode encontrar.

400: Pedido errado

Problema: ao fazer um carregamento retomável, recebi este erro e a mensagem Failed to parse Content-Range header.

Solução: o valor que usou no cabeçalho Content-Range é inválido. Por exemplo, Content-Range: */* é inválido e, em alternativa, deve ser especificado como Content-Range: bytes */*. Se receber este erro, o carregamento retomável atual já não está ativo e tem de iniciar um novo carregamento retomável.

400: erros específicos da inteligência de armazenamento

As secções seguintes descrevem erros comuns que pode encontrar quando configura ou gere a inteligência de armazenamento para um recurso.

400: nome do contentor inválido

Problema: quando configura ou gere a inteligência de armazenamento para um recurso, pode receber este erro e a mensagem The specific bucket is not valid.

Solução: o URL que usou no pedido é inválido. O URL tem de cumprir os seguintes requisitos:

• locations/global é a única localização suportada para a inteligência de armazenamento. A utilização de qualquer outra localização não é suportada.
• Storage Intelligence está no singular no URL e não no plural.

Segue-se um exemplo de um URL válido:

curl -X PATCH -H "Content-Type: application/json" -d
    '{"edition_config": "STANDARD" }'
    -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://storage.s3nsapis.fr/v2/projects/my-project/locations/global/storageIntelligence?updateMask=edition_config"

400: Invalid Argument - Empty Update Mask

Problema: quando configura ou gere a inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Empty UPDATE_MASK in the request.

Solução: UPDATE_MASK é a lista de nomes de campos separados por vírgulas que o pedido atualiza. Os nomes dos campos usam o formato FieldMask e fazem parte do recurso StorageIntelligence. Para atualizar a configuração do Storage Intelligence de um recurso, use um UPDATE_MASK válido no pedido. Não é suportado um valor vazio.

400: caminho da máscara de atualização inválido

Problema: quando configura ou gere a inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Invalid UPDATE_MASK paths.

Solução: se usar um nome de campo inválido no UPDATE_MASK, recebe uma mensagem de erro. UPDATE_MASK é a lista separada por vírgulas dos nomes dos campos que a solicitação atualiza. Os nomes dos campos usam o formato FieldMask e fazem parte do recurso IntelligenceConfig. Para atualizar a configuração da inteligência de armazenamento de um recurso, certifique-se de que todos os nomes de campos indicados em UPDATE_MASK são campos válidos no recurso IntelligenceConfig.

400: Field Is Not Editable

Problema: quando configura ou gere a inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Invalid UPDATE_MASK: UPDATE_TIME field is not editable.

Solução: UPDATE_MASK é a lista de nomes de campos separados por vírgulas que o pedido atualiza. Os nomes dos campos usam o formato FieldMask e fazem parte do recurso IntelligenceConfig. Se tentar atualizar um campo que não é editável, recebe uma mensagem de erro. Remova o campo não editável de Update_Mask e tente novamente.

400: valor inválido

Problema: quando configura ou gere a inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Invalid value at storage_intelligence.edition_config.

Solução: se tentar usar um valor inválido para o campo edition_config, recebe uma mensagem de erro. Os valores permitidos são INHERIT, STANDARD e DISABLED. Reveja o valor e tente novamente.

400: filtro não vazio

Problema: quando atualiza a configuração da inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration.

Solução: quando atualiza o Storage Intelligence edition_config para INHERIT ou DISABLED, não pode usar filtros de contentores no pedido. Remova os filtros do pedido e tente novamente.

400: Empty Location Or Bucket Values In Filter

Problema: quando atualiza a configuração da inteligência de armazenamento para um recurso, pode receber este erro e a mensagem Empty location or bucket values in filter.

Solução: quando atualiza a configuração da Storage Intelligence e usa um filtro de contentores no pedido, ocorre um erro se o valor de location ou bucket for uma string vazia. Indique um valor válido para location ou bucket e tente novamente.

401: não autorizado

Problema: os pedidos a um contentor público diretamente estão a falhar com um erro HTTP 401: Unauthorized e uma resposta Authentication Required.

Solução: verifique se o seu cliente ou qualquer proxy intermédio não está a adicionar um cabeçalho Authorization às solicitações para o Cloud Storage. Qualquer pedido com um cabeçalho Authorization, mesmo que esteja vazio, é validado como se fosse uma tentativa de autenticação.

403: conta desativada

Problema: tentei criar um contentor, mas recebi um erro 403 Account Disabled.

Solução: este erro indica que ainda não ativou a faturação para o projeto associado. Para ver os passos para ativar a faturação, consulte o artigo Ative a faturação para um projeto.

403: Proibido

Problema: devia ter autorização para aceder a um determinado contentor ou objeto, mas, quando tento fazê-lo, recebo um erro 403 - Forbidden com uma mensagem semelhante a: example@email.com does not have storage.objects.get access to the Google Cloud Storage object.

Solução: não tem uma autorização de IAM para o contentor ou o objeto necessária para concluir o pedido. Se espera poder fazer o pedido, mas não consegue, faça as seguintes verificações:

1. O beneficiário referenciado na mensagem de erro é o que esperava? Se a mensagem de erro se referir a um endereço de email inesperado ou a "Autor anónimo", o seu pedido não está a usar as credenciais pretendidas. Isto pode dever-se ao facto de a ferramenta que está a usar para fazer o pedido ter sido configurada com as credenciais de outro alias ou entidade, ou o pedido pode estar a ser feito em seu nome por uma conta de serviço.

2. A autorização referenciada na mensagem de erro é uma autorização que pensava que precisava? Se a autorização for inesperada, é provável que a ferramenta que está a usar precise de acesso adicional para concluir o seu pedido. Por exemplo, para eliminar objetos em massa num contentor, o gcloud tem primeiro de criar uma lista de objetos no contentor a eliminar. Esta parte da ação de eliminação em massa requer a autorização storage.objects.list, o que pode ser surpreendente, uma vez que o objetivo é a eliminação de objetos, que normalmente requer apenas a autorização storage.objects.delete. Se esta for a causa da sua mensagem de erro, certifique-se de que lhe são concedidas funções do IAM que tenham as autorizações adicionais necessárias.

3. Tem a função IAM no recurso pretendido ou no recurso principal? Por exemplo, se lhe for concedido o papel Storage Object Viewer para um projeto e estiver a tentar transferir um objeto, certifique-se de que o objeto está num contentor que se encontra no projeto. Pode ter inadvertidamente a autorização Storage Object Viewer para um projeto diferente.

4. A sua autorização para aceder a um determinado contentor ou objeto é concedida através de um valor de conveniência? A remoção do acesso concedido a um valor de conveniência pode fazer com que os diretores anteriormente ativados percam o acesso aos recursos.

   Por exemplo, suponhamos que jane@example.com tem a função básica de proprietário (roles/owner) para um projeto denominado my-example-project e que a política de IAM do projeto concede a função de criador de objetos de armazenamento (roles/storage.objectCreator) ao valor de conveniência projectOwner:my-example-project. Isto significa que jane@example.com tem as autorizações associadas à função de criador de objetos de armazenamento para contentores em my-example-project. Se esta concessão for removida, jane@example.com perde as autorizações associadas à função de criador de objetos de armazenamento.

   Neste caso, pode recuperar o acesso ao contentor ou ao objeto concedendo-se as autorizações necessárias ao nível do contentor ou do objeto para realizar as ações de que precisa.

5. Existe uma política de negação do IAM que impede a utilização de determinadas autorizações? Pode contactar o administrador da sua organização para saber se foi implementada uma política de recusa do IAM.

403: autorização recusada

Problema: erro de acesso recusado quando configura ou gere a configuração da Storage Intelligence para um recurso.

Solução: se receber um erro de acesso recusado com uma mensagem semelhante a permission storage.intelligenceConfigs.update quando configurar e gerir a inteligência de armazenamento para um recurso, consulte a secção de autorizações para a operação que quer realizar. Para resolver este problema, conceda as autorizações adequadas. Pode conceder autorizações de qualquer uma das seguintes formas:

• Conceda autorizações de IAM na mesma hierarquia de recursosTrusted Cloud by S3NS que está a ativar a inteligência de armazenamento.
• Certifique-se de que um recurso mais elevado na Trusted Cloud by S3NS hierarquia de recursos transmite as autorizações ao recurso secundário.

409: Conflito

Problema: tentei criar um contentor, mas recebi o seguinte erro:

409 Conflict. Sorry, that name is not available. Please try a different one.

Solução: o nome do contentor que tentou usar (por exemplo, gs://cats ou gs://dogs) já está a ser usado. O Cloud Storage tem um espaço de nomes global, pelo que não pode dar a um contentor o mesmo nome de um contentor existente. Escolha um nome que não esteja a ser usado.

412: restrições personalizadas violadas

Problema: os meus pedidos estão a ser rejeitados com um erro 412 orgpolicy.

Problema: os meus pedidos estão a ser rejeitados com um erro 412 Multiple constraints were violated.

Solução: verifique junto da sua equipa de administração de segurança se o contentor para o qual está a enviar pedidos está a ser afetado por uma política da organização que usa uma restrição personalizada. O seu contentor também pode ser afetado por diferentes políticas organizacionais que entram em conflito entre si. Por exemplo, quando uma política especifica que os contentores têm de ter a classe de armazenamento Standard e outra política especifica que os contentores têm de ter a classe de armazenamento Coldline.

429: demasiados pedidos

Problema: os meus pedidos estão a ser rejeitados com um erro 429 Too Many Requests.

Solução: está a atingir um limite para o número de pedidos que o Cloud Storage permite para um determinado recurso. Consulte as quotas do Cloud Storage para uma discussão sobre os limites no Cloud Storage.

• Se a sua carga de trabalho consistir em milhares de pedidos por segundo para um contentor, consulte as diretrizes de taxa de pedidos e distribuição de acesso para uma discussão das práticas recomendadas, incluindo o aumento gradual da carga de trabalho e a evicção de nomes de ficheiros sequenciais.

• Se a sua carga de trabalho estiver potencialmente a usar 50 Gbps ou mais de saída de rede para localizações específicas, verifique a sua utilização de largura de banda para garantir que não está a ter problemas com uma quota de largura de banda.

Diagnosticar Trusted Cloud erros da consola

Problema: quando uso a Trusted Cloud consola para realizar uma operação, recebo uma mensagem de erro genérica. Por exemplo, vejo uma mensagem de erro quando tento eliminar um contentor, mas não vejo detalhes sobre o motivo da falha da operação.

Solução: use as notificações da Trusted Cloud consola Trusted Cloud para ver informações detalhadas sobre a operação com falha:

1. Clique no botão Notificações (notifications) no Trusted Cloud cabeçalho da consola.

   Um menu pendente apresenta as operações mais recentes realizadas pela Trusted Cloud consola.

2. Clique no item sobre o qual quer saber mais.

   É apresentada uma página com informações detalhadas sobre a operação.

3. Clique em cada linha para expandir as informações detalhadas sobre o erro.

Problema: quando uso a Trusted Cloud consola, não vejo uma coluna específica apresentada.

Solução: para ver uma coluna específica apresentada na Trusted Cloud consola, clique no ícone Opções de apresentação de colunas (view_column) e selecione a coluna que quer ver apresentada.

Pastas simuladas e pastas geridas

Problema: eliminei alguns objetos no meu contentor e, agora, a pasta que os continha não aparece na Trusted Cloud consola.

Solução: embora a Trusted Cloud consola apresente o conteúdo do seu contentor como se existisse uma estrutura de diretórios, as pastas não existem fundamentalmente no Cloud Storage. Como resultado, quando remove todos os objetos com um prefixo comum de um contentor, o ícone da pasta que representa esse grupo de objetos deixa de aparecer na consola. Trusted Cloud

Problema: não consigo criar pastas geridas.

Solução: para criar pastas geridas, certifique-se de que os seguintes requisitos são cumpridos:

• Tem uma função de IAM que contém a autorização storage.managedfolders.create, como a função de administrador de objetos de armazenamento (roles/storage.objectAdmin). Para ver instruções sobre como conceder funções, consulte o artigo Use autorizações de IAM.

• O acesso uniforme ao nível do contentor está ativado no contentor no qual quer criar pastas geridas.

• Não existem condições de IAM no contentor ou no projeto que usem o tipo de recurso de contentor (storage.googleapis.com/Bucket) ou o tipo de recurso de objeto (storage.googleapis.com/Object). Se algum contentor num projeto tiver uma condição de IAM que use qualquer um destes tipos de recursos, não é possível criar pastas geridas em nenhum dos contentores nesse projeto, mesmo que a condição seja removida posteriormente.

Problema: não consigo desativar o acesso uniforme ao nível do contentor porque existem pastas geridas no meu contentor.

Solução: não é possível desativar o acesso uniforme ao nível do contentor se existirem pastas geridas no contentor. Para desativar o acesso uniforme ao nível do contentor, tem de eliminar primeiro todas as pastas geridas no contentor.

Tornar os dados públicos

Problema: estou a tentar tornar os meus dados públicos, mas recebo um erro de política da organização.

Solução: algumas restrições de políticas da organização podem impedir que torne os seus dados públicos. Por exemplo, a restrição de partilha restrita ao domínio (constraints/iam.allowedPolicyMemberDomains) restringe a partilha de recursos com base no domínio da organização. Para falhas da política de organização, contacte o seu administrador para lhe conceder as autorizações ao nível do projeto ou do contentor para permitir a partilha de recursos editando a política de organização para o recurso de organização, pasta ou projeto. Se continuar a ver este erro depois de substituir a política da organização, pode ter de aguardar alguns minutos para que a alteração entre em vigor.

Problema: recebo um erro de autorização quando tento tornar os meus dados públicos.

Solução: certifique-se de que tem a autorização storage.buckets.setIamPolicy ou a autorização storage.objects.setIamPolicy. Estas autorizações são concedidas, por exemplo, na função de administrador de armazenamento (roles/storage.admin). Se tiver a autorização storage.buckets.setIamPolicy ou a autorização storage.objects.setIamPolicy e continuar a receber um erro, o seu contentor pode estar sujeito à prevenção de acesso público, que não permite o acesso a allUsers nem a allAuthenticatedUsers. A prevenção de acesso público pode ser definida diretamente no contentor ou pode ser aplicada através de uma política da organização definida a um nível superior.

Latência

Seguem-se problemas de latência comuns que pode encontrar. Além disso, o Trusted Cloud by S3NS painel de controlo do estado do serviço fornece informações sobre incidentes que afetam os Trusted Cloud by S3NS serviços, como o Cloud Storage.

Latência de carregamento ou transferência

Problema: estou a verificar um aumento da latência ao carregar ou transferir ficheiros.

Solução: considere as seguintes causas comuns de latência de carregamento e transferência:

• Restrições de CPU ou memória: o sistema operativo do ambiente afetado deve ter ferramentas para medir o consumo de recursos locais, como a utilização da CPU e a utilização de memória.

• Restrições de E/S de disco: o impacto no desempenho pode ser causado pela E/S de disco local.

• Distância geográfica: o desempenho pode ser afetado pela separação física do contentor do Cloud Storage e do ambiente afetado, particularmente em casos intercontinentais. Os testes com um contentor localizado na mesma região que o ambiente afetado podem identificar a medida em que a separação geográfica está a contribuir para a latência.

  • Se aplicável, o resolvedor de DNS do ambiente afetado deve usar o protocolo EDNS(0) para que os pedidos do ambiente sejam encaminhados através de um front-end da Google adequado.

Latência da CLI ou da biblioteca cliente

Problema: estou a observar um aumento da latência ao aceder ao Cloud Storage com a CLI Google Cloud ou uma das bibliotecas de cliente.

Solução: a CLI gcloud e as bibliotecas de cliente voltam a tentar automaticamente os pedidos quando é útil fazê-lo, e este comportamento pode aumentar eficazmente a latência vista pelo utilizador final. Use a métrica do Cloud Monitoring storage.googleapis.com/api/request_count para ver se o Cloud Storage está a publicar consistentemente um código de resposta repetível, como 429 ou 5xx.

Servidores proxy

Problema: estou a estabelecer ligação através de um servidor proxy. O que necessito de fazer?

Solução: para aceder ao Cloud Storage através de um servidor proxy, tem de permitir o acesso a estes domínios:

• accounts.google.com para criar símbolos de autenticação OAuth2
• oauth2.googleapis.com para realizar trocas de tokens OAuth2
• *.googleapis.com para pedidos de armazenamento

Se o seu servidor proxy ou política de segurança não suportar a adição de domínios à lista de autorizações e, em alternativa, suportar apenas a adição de blocos de rede IP à lista de autorizações, recomendamos vivamente que configure o seu servidor proxy para todos os intervalos de endereços IP da Google. Pode encontrar os intervalos de endereços consultando os dados do WHOIS no ARIN. Como prática recomendada, deve rever periodicamente as definições de proxy para garantir que correspondem aos endereços IP da Google.

Não recomendamos que configure o seu proxy com endereços IP individuais que obtém de pesquisas únicas de oauth2.googleapis.com e storage.s3nsapis.fr. Uma vez que os serviços Google são expostos através de nomes DNS que mapeiam um grande número de endereços IP que podem mudar ao longo do tempo, a configuração do proxy com base numa pesquisa única pode levar a falhas na ligação ao Cloud Storage.

Se os seus pedidos estiverem a ser encaminhados através de um servidor proxy, pode ter de contactar o administrador de rede para garantir que o cabeçalho que contém as suas credenciais não é removido pelo proxy.Authorization Sem o cabeçalho Authorization, os seus pedidos são rejeitados e recebe um erro MissingSecurityHeader.

O que se segue?

• Encontre respostas a perguntas adicionais nas Perguntas frequentes do Cloud Storage.