Proceso de firma de V2

Importante: En esta página, se trata material heredado relacionado con el proceso de firma de V2. Se recomienda que, en cambio, los usuarios trabajen con el proceso de firma de V4.

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.

Importante: Las URLs firmadas solo pueden usarse para acceder a recursos en Cloud Storage a través de extremos de la API de XML.

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:

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

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.

Nota: La firma no verifica los parámetros de string de consulta, como response-content-disposition y response-content-type. Para forzar un Content-Disposition o Content-Type en la respuesta, configura esos parámetros en los metadatos del objeto.

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

Si quieres obtener asistencia en otros idiomas, consulta Descripción general de la API de App Identity para Java, Descripción general de la API de App Identity para PHP y Descripción general de la API de App Identity para las funciones de Go.

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:

1. Crea todos los nombres de encabezados personalizados en minúsculas.

2. Ordena todos los encabezados personalizados por nombre de encabezado con un orden lexicográfico por el valor de puntos de código.

3. 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ó.

4. 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.

5. 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.

6. Quita los espacios en blanco alrededor de los dos puntos que aparecen después del nombre del encabezado.

7. Agrega un salto de línea “\n” (U + 000A) a cada encabezado personalizado.

8. Concatena todos los encabezados personalizados.

Importante: Debes usar el nombre y el valor del encabezado cuando crees la parte de la string de la consulta de los encabezados de extensión canónica. Asegúrate de quitar cualquier espacio en blanco alrededor de los dos puntos que separan el nombre y el valor del encabezado. Por ejemplo, si usas el encabezado predeterminado x-goog-acl: private sin quitar el espacio luego de los dos puntos, se mostrará el error 403 Forbidden, debido a que la firma de solicitud que tú determinas no coincide con la que determina Cloud Storage.

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.