Processo de assinatura V2

Importante: nesta página, você verá informações sobre materiais legados relativos ao processo de assinatura V2. No entanto, recomenda-se que os usuários trabalhem com o processo de assinatura V4.

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. Os URLs assinados são uma ótima maneira de conceder acesso limitado de leitura ou gravação a qualquer pessoa que tenha o URL, mesmo que ela não tenha uma conta de usuário.

Importante: as URLs assinadas podem ser usadas apenas para acessar recursos no Cloud Storage por meio de endpoints da API XML.

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.
Content_MD5	rmYdCNHKFXam78uCt7xQLw==	Opcional. O valor do resumo do MD5 em Base64. Se você fornecer 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.

Observação: os parâmetros de string de consulta como response-content-disposition e response-content-type não são confirmados pela assinatura. Para forçar um Content-Disposition ou um Content-Type na resposta, defina esses parâmetros nos metadados do objeto.

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 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, usando a API App Identity para Python, você pode:

• 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 RFC 7230, seção 3.2.4 (em inglês).

6. Remova qualquer espaço em branco em volta do sinal de dois pontos que aparece 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.

Importante: é necessário usar o nome e o valor do cabeçalho ao construir a parte de cabeçalhos de extensão canônicos da string de consulta. Remova qualquer espaço em branco em volta dos dois-pontos que separam o nome e o valor do cabeçalho. Por exemplo, usar o cabeçalho personalizado x-goog-acl: private sem remover o espaço depois dos dois-pontos retorna um erro 403 Forbidden, porque a assinatura da solicitação que você calcula não corresponde à assinatura que o Cloud Storage calcula.

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.