Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
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.
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:
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.
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.
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:
Coloque todos os nomes de cabeçalho personalizados em letra minúscula.
Classifique todos os cabeçalhos personalizados por nome usando uma classificação lexicográfica por pontuação de código.
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.
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).
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).
Remova qualquer espaço em branco em volta do sinal de dois pontos que aparece após o nome do cabeçalho.
Anexe um "\n" de nova linha (U+000A) a cada cabeçalho personalizado.
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.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-05 UTC."],[],[],null,["# V2 Signing Process\n\n| **Important:** This page covers legacy material related to the V2 signing process. It is recommended that users work with the [V4 signing process](/storage/docs/access-control/signed-urls) instead.\n\nThis page provides an overview of signed URLs when working with the V2 signing\nprocess, which is a mechanism for query\nstring authentication for buckets and objects.\nSigned URLs provide a way to give time-limited read or write access to anyone\nin possession of the URL, regardless of whether they have a user account.\n| **Important:** Signed URLs can only be used to access resources in Cloud Storage through [XML API endpoints](/storage/docs/request-endpoints).\n\nComponents of the string that requires signing\n----------------------------------------------\n\nWhen creating a signed URL using a program, your program constructs a string\nthat will be signed. This string should be defined in your program as: \n\n```\nStringToSign = HTTP_Verb + \"\\n\" +\n Content_MD5 + \"\\n\" +\n Content_Type + \"\\n\" +\n Expires + \"\\n\" +\n Canonicalized_Extension_Headers +\n Canonicalized_Resource\n```\n\nThe components that make up this structure are described in the following table:\n\n| **Note:** Query String Parameters like `response-content-disposition` and `response-content-type` are not verified by the signature. To force a `Content-Disposition` or `Content-Type` in the response, [set those parameters in the object metadata](/storage/docs/viewing-editing-metadata#edit).\n\nSigning strings with the App Engine App Identity service\n--------------------------------------------------------\n\nWhen creating a signed URL using a program, you can either sign the string\nfrom within your program, or else from\nwithin a App Engine application using the App Engine Identity service,\nwhich uses App Engine's service account credentials. For example, using the\n[Python App Identity API](/appengine/docs/python/appidentity), you can:\n\n- Use `google.appengine.api.app_identity.sign_blob()` to sign the bytes from\n your constructed string, providing the `Signature` you need when\n assembling the signed URL.\n\n- Use `google.appengine.api.app_identity.get_service_account_name()`\n to retrieve a service account name, which is the `GoogleAccessId` you need\n when assembling the signed URL.\n\nFor support in other languages, see\n[App Identity API for Java Overview](/appengine/docs/java/appidentity),\n[App Identity API for PHP Overview](/appengine/docs/php/appidentity),\nand [App Identity Go Functions](/appengine/docs/go/appidentity).\n\nThe App Identity service rotates the private keys when it signs blobs. Signed URLs\ngenerated from the App Identity service are good for at least one hour, and are best used for\nshort-lived access to resources.\n\nCanonical extension headers\n---------------------------\n\nWhen creating a signed URL using a program, you construct the Canonical\nExtension Headers portion of the message by concatenating all\nextension (custom) headers that begin with `x-goog-`. However, you cannot perform a simple\nconcatenation. Keep the following algorithm in mind as you create the headers:\n\n1. Make all custom header names lowercase.\n\n2. Sort all custom headers by header name using a lexicographical sort by code point value.\n\n3. If present, remove the `x-goog-encryption-key` and `x-goog-encryption-key-sha256`\n headers. These headers contain sensitive information that must not be included\n in the string-to-sign; however, these headers must still be used in any\n requests that use the generated signed URL.\n\n4. Eliminate duplicate header names by creating one header name with a comma-separated list of\n values. Be sure there is no whitespace between the values, and be sure that the order of the\n comma-separated list matches the order that the headers appear in your request. For more\n information, see [RFC 7230 section 3.2](https://datatracker.ietf.org/doc/html/rfc7230#section-3.2).\n\n5. Replace any folding whitespace or newlines (CRLF or LF) with a single space. For more\n information about folding whitespace, see\n [RFC 7230, section 3.2.4.](https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.4).\n\n6. Remove any whitespace around the colon that appears after the header name.\n\n7. Append a newline \"\\\\n\" (U+000A) to each custom header.\n\n8. Concatenate all custom headers.\n\n| **Important:** You must use both the header name and the header value when you construct the Canonical Extension Headers portion of the query string. Be sure to remove any whitespace around the colon that separates the header name and value. For example, using the custom header `x-goog-acl: private` without removing the space after the colon returns a `403 Forbidden` error, because the request signature you calculate does not match the signature Cloud Storage calculates.\n\nCanonical resources\n-------------------\n\nWhen creating a signed URL using a program, you construct the\nCanonicalized Resource portion of the message by concatenating the resource\npath (bucket and object and subresource) that the request is acting on. Keep\nthe following in mind as you create the resource:\n\n- The canonical resource is everything that follows the host name. For example,\n if the Cloud Storage URL is `https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg`,\n then the canonical resource is `/example-bucket/cat-pics/tabby.jpeg`.\n\n- If the request is scoped to a subresource, such as `?cors`, add this subresource,\n including the question mark, to the end of the string.\n\n- Be sure to copy the HTTP request path literally: that is, you should include all URL encoding\n (percent signs) in the string that you create. Also, be sure that you include only query string\n parameters that designate subresources (such as `cors`). You should not include query string\n parameters such as `?prefix`, `?max-keys`, `?marker`, and `?delimiter`."]]
