Processo de assinatura V2

Importante: esta página aborda material antigo relacionado com o processo de assinatura da versão 2. Em alternativa, recomenda-se que os utilizadores trabalhem com o processo de assinatura da V4.

Esta página fornece uma vista geral dos URLs assinados quando trabalha com o processo de assinatura V2, que é um mecanismo de autenticação de strings de consulta para contentores e objetos. Os URLs assinados oferecem uma forma de conceder acesso de leitura ou escrita por tempo limitado a qualquer pessoa que tenha o URL, independentemente de ter ou não uma conta de utilizador.

Importante: os URLs assinados só podem ser usados para aceder a recursos no armazenamento na nuvem através de endpoints da API XML.

Componentes da string que requerem assinatura

Quando cria um URL assinado através de um programa, o programa cria uma string que vai ser assinada. Esta string deve ser definida no seu programa da seguinte forma:

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

Os componentes que constituem esta estrutura estão descritos na tabela seguinte:

Componente de string	Exemplo	Descrição
HTTP_Verb	GET	Obrigatório. O verbo HTTP a usar com o URL assinado. Nota: o verbo HTTP POST não é suportado em strings de URL assinado, exceto conforme indicado acima. Pode usar o método POST para definir documentos de políticas assinados, que especificam as caraterísticas dos objetos que podem ser carregados para um contentor. Saiba mais na documentação POST Object.
Content_MD5	rmYdCNHKFXam78uCt7xQLw==	Opcional. O valor de resumo MD5 em Base64. Se fornecer esta informação na string, o cliente (normalmente, um navegador) tem de fornecer este cabeçalho HTTP com este mesmo valor no respetivo pedido.
Content_Type	text/plain	Conforme necessário. Se fornecer um content-type, o cliente (navegador) tem de fornecer este cabeçalho HTTP definido com o mesmo valor.
Expires	1388534400	Obrigatório. Esta é a data/hora (representada como o número de segundos desde a época Unix de 00:00:00 UTC a 1 de janeiro de 1970) em que a assinatura expira. O servidor rejeita todos os pedidos recebidos após esta data/hora, bem como todos os pedidos recebidos após a rotação da chave usada para gerar o URL assinado. Por motivos de segurança e de compatibilidade com o processo de assinatura da V4, deve definir Expires para corresponder, no máximo, a 1 semana (604 800 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 nos pedidos através do URL assinado. Para ver informações sobre como criar cabeçalhos canónicos para assinatura, consulte o artigo Cabeçalhos de extensão canónicos.
Canonicalized_Resource	/bucket/objectname	Obrigatório. O recurso que está a ser abordado no URL. Para ver mais detalhes, consulte o artigo Recursos canónicos.

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

Assinar strings com o serviço App Identity do App Engine

Quando cria um URL assinado através de um programa, pode assinar a string a partir do programa ou a partir de uma aplicação do App Engine através do serviço de identidade do App Engine, que usa as credenciais da conta de serviço do App Engine. Por exemplo, com a API Python App Identity, pode:

• Use google.appengine.api.app_identity.sign_blob() para assinar os bytes da string criada, fornecendo o Signature necessário ao montar o URL assinado.

• Use google.appengine.api.app_identity.get_service_account_name() para obter um nome de conta de serviço, que é o GoogleAccessId de que precisa ao criar o URL assinado.

Para receber apoio técnico noutros idiomas, consulte os artigos Vista geral da API App Identity para Java, Vista geral da API App Identity para PHP e Funções Go da API App Identity.

O serviço de identidade da app altera as chaves privadas quando assina blobs. Os URLs assinados gerados a partir do serviço de identidade da app são válidos durante, pelo menos, uma hora e são mais adequados para o acesso de curta duração aos recursos.

Cabeçalhos de extensões canónicas

Quando cria um URL assinado através de um programa, cria a parte dos cabeçalhos de extensão canónicos da mensagem concatenando todos os cabeçalhos de extensão (personalizados) que começam por x-goog-. No entanto, não pode fazer uma simples concatenação. Tenha em atenção o seguinte algoritmo ao criar os cabeçalhos:

1. Converter todos os nomes de cabeçalhos personalizados em minúsculas.

2. Ordene todos os cabeçalhos personalizados por nome do cabeçalho através de uma ordenação lexicográfica por valor do ponto de código.

3. Se presentes, remova os cabeçalhos x-goog-encryption-key e x-goog-encryption-key-sha256. Estes cabeçalhos contêm informações confidenciais que não devem ser incluídas na string a assinar. No entanto, estes cabeçalhos têm de ser usados em todos os pedidos que usem o URL assinado gerado.

4. Elimine nomes de cabeçalhos duplicados criando um nome de cabeçalho com uma lista de valores separados por vírgulas. Certifique-se de que não existe nenhum espaço entre os valores e de que a ordem da lista separada por vírgulas corresponde à ordem em que os cabeçalhos aparecem no seu pedido. Para mais informações, consulte a secção 3.2 do RFC 7230.

5. Substitua qualquer espaço em branco de dobragem ou novas linhas (CRLF ou LF) por um único espaço. Para mais informações sobre a união de espaços em branco, consulte a secção 3.2.4 do RFC 7230.

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

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

8. Concatenar todos os cabeçalhos personalizados.

Importante: tem de usar o nome e o valor do cabeçalho quando cria a parte dos cabeçalhos de extensão canónicos da string de consulta. Certifique-se de que remove todos os espaços em branco à 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 após os dois pontos devolve um erro 403 Forbidden, porque a assinatura do pedido que calcula não corresponde à assinatura que o Cloud Storage calcula.

Recursos canónicos

Quando cria um URL assinado através de um programa, cria a parte do recurso canónico da mensagem concatenando o caminho do recurso (contentor, objeto e sub-recurso) sobre o qual o pedido está a atuar. Tenha em atenção o seguinte ao criar o recurso:

• O recurso canónico é tudo o que se segue ao nome do anfitrião. Por exemplo, se o URL do Cloud Storage for https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg, o recurso canónico é /example-bucket/cat-pics/tabby.jpeg.

• Se o pedido estiver no âmbito de um subrecurso, como ?cors, adicione este subrecurso, incluindo o ponto de interrogação, no final da string.

• Certifique-se de que copia literalmente o caminho do pedido HTTP, ou seja, deve incluir toda a codificação de URL (sinais de percentagem) na string que criar. Além disso, certifique-se de que inclui apenas parâmetros da string de consulta que designam subrecursos (como cors). Não deve incluir parâmetros da string de consulta, como ?prefix, ?max-keys, ?marker e ?delimiter.