Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se proporciona una descripción general de las URLs firmadas cuando se trabaja con el proceso de firma de V2, que es un mecanismo para autenticar las cadenas de consulta para buckets y objetos.
Las URLs firmadas proporcionan una forma de otorgar acceso de lectura o escritura por tiempo limitado a cualquier persona que posea la URL, sin importar si tiene una cuenta de usuario.
Componentes de la string que necesita firma
Cuando creas una URL firmada con un programa, tu programa crea una string que se deberá firmar. Esta string debe definirse en tu programa de la siguiente manera:
Los componentes que forman esta estructura se describen en la siguiente tabla:
Componente de la string
Ejemplo
Descripción
HTTP_Verb
GET
Obligatorio. El verbo HTTP que se usará con la URL firmada.
Nota: El verbo HTTP POST no se admite en strings de URL firmadas, excepto en los casos que se indicaron con anterioridad. Puedes usar POST para definir documentos de políticas firmados, que especifican las características de los objetos que se pueden subir a un bucket. Obtén más información en la documentación sobre objetos POST.
Content_MD5
rmYdCNHKFXam78uCt7xQLw==
Opcional. El valor de resumen de MD5 en Base64. Si proporcionas esto en la string, el cliente (por lo general, un navegador) debe proporcionar este encabezado HTTP con este mismo valor en su solicitud.
Content_Type
text/plain
Según sea necesario. Si proporcionas un content-type, el cliente (navegador) debe proporcionar este conjunto de encabezados HTTP con el mismo valor.
Expires
1388534400
Obligatorio. Esta es la marca de tiempo (representada como el número de segundos desde la época Unix del UTC 00:00:00 el 1 de enero de 1970) cuando se vence la firma. El servidor rechaza cualquier solicitud recibida después de esta marca de tiempo, así como cualquier solicitud recibida después de rotar la clave que se usó para generar la URL firmada. Por motivos de seguridad y compatibilidad con el proceso de firma de V4, debes configurar Expires para que corresponda, como máximo, a 1 semana (604800 segundos) en el futuro.
Canonicalized_Extension_Headers
x-goog-acl:public-read\nx-goog-meta-foo:bar,baz\n
Según sea necesario. El servidor realiza una verificación a fin de asegurarse de que el cliente proporcione valores coincidentes en las solicitudes con la URL firmada. Si deseas obtener información sobre cómo crear encabezados canónicos para firmar, consulta Encabezados de extensión canónicos.
Canonicalized_Resource
/bucket/objectname
Obligatorio. El recurso que se aborda en la URL. Para obtener más detalles, consulta Recursos canónicos.
Firma strings con el servicio App Identity de App Engine
Cuando creas una URL firmada con un programa, puedes firmar la cadena
desde tu programa o desde una
aplicación de App Engine con el servicio Identity de App Engine,
que usa las credenciales de la cuenta de servicio de App Engine. Por ejemplo, si usas la API de App Identity para Python, puedes hacer lo siguiente:
Usar google.appengine.api.app_identity.sign_blob() para firmar los bytes de tu string creada, lo cual proporciona la Signature que necesitas cuando ensamblas la URL firmada
Usar google.appengine.api.app_identity.get_service_account_name() para recuperar un nombre de cuenta de servicio, que es el GoogleAccessId que necesitas cuando ensamblas la URL firmada
El servicio de App Identity rota las claves privadas cuando firma los BLOB. Las URL firmadas generadas desde el servicio de App Identity son útiles durante una hora como mínimo y se usan mejor para el acceso a los recursos de corta duración.
Encabezados de extensión canónica
Cuando creas una URL firmada con un programa, creas la parte del mensaje de los encabezados de extensión canónica mediante la concatenación de todos los encabezados de extensión (personalizados) que comienzan con x-goog-. Sin embargo, no puedes realizar una concatenación simple. Ten en cuenta el siguiente algoritmo cuando crees los encabezados:
Crea todos los nombres de encabezados personalizados en minúsculas.
Ordena todos los encabezados personalizados por nombre de encabezado con un orden lexicográfico por el valor de puntos de código.
Si existen, quita los encabezados x-goog-encryption-key y x-goog-encryption-key-sha256. Estos encabezados contienen información sensible que no se debe incluir en la string para firmar; sin embargo, se deben usar en cualquier solicitud que use la URL firmada que se generó.
Borra los nombres de encabezados duplicados. Puedes hacerlo si creas un nombre de encabezado con una lista de valores separada por comas. Asegúrate de que no haya espacios en blanco entre los valores y de que el orden de la lista separada por comas coincida con el orden en que aparecen los encabezados en su solicitud. Para obtener más información, consulta RFC 7230 sección 3.2.
Reemplaza cualquier espacio en blanco plegable o salto de línea (CRLF o LF) con un solo espacio. Para obtener más información sobre el plegado de espacios en blanco, consulta RFC 7230, sección 3.2.4.
Quita los espacios en blanco alrededor de los dos puntos que aparecen después del nombre del encabezado.
Agrega un salto de línea “\n” (U + 000A) a cada encabezado personalizado.
Concatena todos los encabezados personalizados.
Recursos canónicos
Cuando creas una URL firmada con un programa, creas la parte del mensaje del recurso canonicalizado mediante la concatenación de la ruta del recurso (bucket, objeto y subrecurso) en el que actúa la solicitud. Ten en cuenta lo siguiente cuando crees el recurso:
El recurso canónico es todo lo que sigue al nombre del host. Por ejemplo, si la URL de Cloud Storage es https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg, entonces el recurso canónico es /example-bucket/cat-pics/tabby.jpeg.
Si la solicitud tiene alcance en un subrecurso, como ?cors, agrega este subrecurso, incluido el signo de interrogación, al final de la string.
Asegúrate de copiar la ruta de solicitud HTTP de forma literal: es decir, debes incluir toda la codificación de URL (signos de porcentaje) en la string que crees. Además, asegúrate de incluir solo parámetros de string de consulta que designen subrecursos (como cors). No debes incluir parámetros de string de consulta como ?prefix, ?max-keys, ?marker y ?delimiter.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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`."]]
