Processo de assinatura V2

Nesta página, você terá uma visão geral das URLs assinados, que é um mecanismo de autenticação de strings de consulta para buckets e objetos, no processo de assinatura V2. As URLs assinados fornecem uma maneira de conceder acesso limitado de leitura ou gravação a qualquer pessoa que tenha a URL, independentemente de ter uma Conta do Google.

Componentes da string que requerem assinatura

Ao criar um URL assinado usando um programa, seu programa constrói uma string que será assinada. Essa string precisa ser definida no seu programa como:

StringToSign = HTTP_Verb + "\n" +
               Content_MD5 + "\n" +
               Content_Type + "\n" +
               Expires + "\n" +
               Canonicalized_Extension_Headers +
               Canonicalized_Resource

Os componentes que compõem essa estrutura estão descritos na tabela a seguir:

Componente da string Exemplo Descrição
HTTP_Verb GET Obrigatório. O verbo HTTP (em inglês) a ser usado com o URL assinado.

Observação: o verbo HTTP POST não é compatível com strings de URL assinado, exceto conforme indicado acima. Use POST para definir documentos de política assinados que especificam as características dos objetos que podem ser carregados em um bucket. Saiba mais na documentação do Objeto POST (em inglês).

Content_MD5 rmYdCNHKFXam78uCt7xQLw== Opcional. O valor do resumo do MD5 em Base64. Se você incluir isso na string, o cliente (geralmente um navegador) precisará fornecer esse cabeçalho HTTP com esse mesmo valor na solicitação.
Content_Type text/plain Conforme necessário. Se você fornecer um content-type (em inglês), o cliente (navegador) precisará fornecer esse cabeçalho HTTP definido com o mesmo valor.
Expires 1388534400 Obrigatório. Carimbo de data/hora (representado como o número de segundos desde a Era Unix de 00:00:00 UTC em 1º de janeiro de 1970) da expiração da assinatura. O servidor rejeita todas as solicitações recebidas após esse carimbo de data/hora, bem como todas as solicitações recebidas após o revezamento da chave usada para gerar o URL assinado. Por motivos de segurança e compatibilidade com o processo de assinatura V4, defina Expires para corresponder a, no máximo, uma semana (604800 segundos) no futuro.
Canonicalized_Extension_Headers x-goog-acl:public-read\nx-goog-meta-foo:bar,baz\n Conforme necessário. O servidor verifica se o cliente fornece valores correspondentes em solicitações que usam o URL assinado. Para informações sobre como criar cabeçalhos canônicos para assinatura, consulte Cabeçalhos de extensão canônicos.
Canonicalized_Resource /bucket/objectname Obrigatório. O recurso que está sendo endereçado no URL. Para mais detalhes, consulte Recursos canônicos.

Como assinar strings com o serviço App Identity do App Engine

Ao criar um URL assinado usando um programa, é possível assinar a string no programa ou em um aplicativo do Google App Engine usando o serviço de identidade do App Engine, que usa as credenciais da conta de serviço do App Engine. Por exemplo, ao usar a API App Identity para Python, é possível fazer o seguinte:

  • Usar google.appengine.api.app_identity.sign_blob() para assinar os bytes da string construída, fornecendo o Signature que você precisa na montagem do URL assinado.

  • Usar google.appengine.api.app_identity.get_service_account_name() para recuperar um nome de conta de serviço, que é o GoogleAccessId que você precisa na montagem do URL assinado.

Para receber suporte em outros idiomas, consulte a Visão geral da API App Identity para Java, a Visão geral da API App Identity para PHP e as Funções do App Identity para Go.

O serviço App Identity faz a rotação das chaves privadas ao assinar os blobs. Os URLs assinados gerados pelo serviço App Identity são válidos por pelo menos uma hora e são melhor utilizados para acesso de curta duração aos recursos.

Cabeçalhos de extensão canônicos

Ao criar um URL assinado usando um programa, você constrói a parte dos cabeçalhos de extensão canônicos da mensagem concatenando todos os cabeçalhos de extensão (personalizados) que começam com x-goog-. No entanto, não é possível executar uma concatenação simples. Lembre-se do algoritmo a seguir ao criar os cabeçalhos:

  1. Coloque todos os nomes de cabeçalho personalizados em letra minúscula.

  2. Classifique todos os cabeçalhos personalizados por nome usando uma classificação lexicográfica por pontuação de código.

  3. Remova os cabeçalhos x-goog-encryption-key e x-goog-encryption-key-sha256 se estiverem presentes. Esses cabeçalhos contêm informações confidenciais que não podem ser incluídas na string a ser assinada. No entanto, eles ainda precisam ser usados em qualquer solicitação que use o URL assinado gerado.

  4. Elimine nomes de cabeçalho duplicados criando um nome de cabeçalho com uma lista de valores separada por vírgula. Verifique se não há espaços em branco entre os valores e se a ordem da lista separada por vírgulas corresponde à ordem em que os cabeçalhos aparecem na solicitação. Para mais informações, consulte a seção 3.2 da RFC 7230 (em inglês).

  5. Substitua qualquer espaço em branco ou novas linhas (CRLF ou LF) por um único espaço. Para mais informações sobre espaços em branco, consulte a RFC 7230, seção 3.2.4 (em inglês).

  6. Remova qualquer espaço em branco em volta dos dois pontos que aparecem após o nome do cabeçalho.

  7. Anexe um "\n" de nova linha (U+000A) a cada cabeçalho personalizado.

  8. Concatene todos os cabeçalhos personalizados.

Recursos canônicos

Ao criar um URL assinado usando um programa, você constrói a parte de recurso canonizado da mensagem, concatenando o caminho do recurso (bucket, objeto e sub-recurso) em que a solicitação está agindo. Lembre-se disto ao criar o recurso:

  • O recurso canônico é tudo o que vem após o nome do host. Por exemplo, se o URL do Cloud Storage for https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg, o recurso canônico será /example-bucket/cat-pics/tabby.jpeg.

  • Se a solicitação tiver escopo para um sub-recurso, como ?cors, adicione esse sub-recurso, incluindo o ponto de interrogação, ao final da string.

  • Copie o caminho da solicitação HTTP literalmente, ou seja, inclua toda codificação de URL (sinais de porcentagem) na string que criar. Além disso, inclua somente os parâmetros da string de consulta que indicam sub-recursos (como cors). Não inclua parâmetros como ?prefix, ?max-keys, ?marker e ?delimiter.