Proceso de firma V2

En esta página se ofrece una descripción general de las URLs firmadas cuando se trabaja con el proceso de firma V2, que es un mecanismo de autenticación de cadenas de consulta para segmentos y objetos. Las URLs firmadas proporcionan una forma de dar acceso de lectura o escritura durante un tiempo limitado a cualquier usuario que disponga de dicha URL, independientemente de si tiene una cuenta de usuario o no.

Componentes de la cadena que requiere una firma

Cuando creas una URL firmada mediante un programa, este crea una cadena que se firmará. Esta cadena debe definirse en su 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 cadena Ejemplo Descripción
HTTP_Verb GET Obligatorio. El verbo HTTP que se va a usar con la URL firmada.

Nota: El verbo HTTP POST no se admite en las cadenas de URLs firmadas, excepto en los casos indicados anteriormente. Puede usar POST para definir documentos de política firmados, que especifican las características de los objetos que se pueden subir a un contenedor. Consulta más información en la documentación de POST Object.

Content_MD5 rmYdCNHKFXam78uCt7xQLw== Opcional. El valor de resumen MD5 en Base64. Si lo proporciona en la cadena, el cliente (normalmente un navegador) debe proporcionar este encabezado HTTP con el mismo valor en su solicitud.
Content_Type text/plain Según sea necesario. Si proporcionas un content-type, el cliente (navegador) debe proporcionar este encabezado HTTP con el mismo valor.
Expires 1388534400 Obligatorio. Es la marca de tiempo (representada como el número de segundos transcurridos desde el inicio del registro de tiempo Unix, es decir, las 00:00:00 UTC del 1 de enero de 1970) en la que caduca la firma. El servidor rechaza las solicitudes recibidas después de esta marca de tiempo, así como las solicitudes recibidas después de que se haya cambiado la clave utilizada para generar la URL firmada. Por motivos de seguridad y para que sea compatible con el proceso de firma V4, debes definir Expires para que corresponda a un plazo de una semana (604.800 segundos) como máximo.
Canonicalized_Extension_Headers x-goog-acl:public-read\nx-goog-meta-foo:bar,baz\n Según sea necesario. El servidor comprueba que el cliente proporcione valores coincidentes en las solicitudes que usen la URL firmada. Para obtener información sobre cómo crear encabezados canónicos para la firma, consulta Encabezados de extensión canónicos.
Canonicalized_Resource /bucket/objectname Obligatorio. El recurso al que se hace referencia en la URL. Para obtener más información, consulta Recursos canónicos.

Firmar cadenas con el servicio de identidad de aplicación de App Engine

Cuando creas una URL firmada mediante un programa, puedes firmar la cadena desde el programa o desde una aplicación de App Engine mediante el servicio de identidad de App Engine, que usa las credenciales de la cuenta de servicio de App Engine. Por ejemplo, con la API App Identity de Python, puedes hacer lo siguiente:

  • Usa google.appengine.api.app_identity.sign_blob() para firmar los bytes de la cadena que has creado y proporciona el Signature que necesitas al ensamblar la URL firmada.

  • Usa google.appengine.api.app_identity.get_service_account_name() para obtener el nombre de una cuenta de servicio, que es el GoogleAccessId que necesitas al crear la URL firmada.

Para obtener asistencia en otros idiomas, consulta los artículos Descripción general de la API App Identity para Java, Descripción general de la API App Identity para PHP y Funciones de Go de App Identity.

El servicio de identidad de la aplicación rota las claves privadas cuando firma blobs. Las URLs firmadas generadas a partir del servicio de identidad de la aplicación son válidas durante al menos una hora y se recomienda usarlas para acceder a recursos durante un periodo breve.

Encabezados de extensión canónicos

Cuando creas una URL firmada mediante un programa, debes crear la parte de los encabezados de extensión canónicos del mensaje concatenando todos los encabezados de extensión (personalizados) que empiecen por x-goog-. Sin embargo, no puedes realizar una concatenación simple. Ten en cuenta el siguiente algoritmo al crear los encabezados:

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

  2. Ordena todos los encabezados personalizados por nombre de encabezado mediante una ordenación lexicográfica por valor de punto de código.

  3. Si los hay, 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 cadena que se va a firmar. Sin embargo, estos encabezados se deben seguir usando en las solicitudes que utilicen la URL firmada generada.

  4. Elimina los nombres de encabezado duplicados creando un nombre de encabezado con una lista de valores separados 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 el que aparecen los encabezados en tu solicitud. Para obtener más información, consulta la sección 3.2 del RFC 7230.

  5. Cambia cualquier espacio en blanco o línea nueva plegable (CRLF o LF) por un espacio sencillo. Para obtener más información sobre los espacios en blanco de plegado, consulta la sección 3.2.4 del RFC 7230.

  6. Elimina todos los espacios en blanco que rodeen los dos puntos que aparecen después del nombre del encabezado.

  7. Añade un salto de línea "\n" (U+000A) a cada encabezado personalizado.

  8. Concatena todos los encabezados personalizados.

Recursos canónicos

Cuando creas una URL firmada mediante un programa, debes crear la parte de recurso canonizado del mensaje concatenando la ruta del recurso (segmento, objeto y subrecurso) sobre el que actúa la solicitud. Ten en cuenta lo siguiente al crear el recurso:

  • El recurso canónico es todo lo que sigue al nombre de host. Por ejemplo, si la URL de Cloud Storage es https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg, el recurso canónico es /example-bucket/cat-pics/tabby.jpeg.

  • Si la solicitud se limita a un subrecurso, como ?cors, añade este subrecurso (incluido el signo de interrogación) al final de la cadena.

  • Asegúrate de copiar literalmente la ruta de solicitud HTTP, es decir, debes incluir toda la codificación de URL (signos de porcentaje) en la cadena que crees. Además, asegúrese de incluir solo los parámetros de cadena de consulta que designen subrecursos (como cors). No debe incluir parámetros de cadena de consulta como ?prefix, ?max-keys, ?marker y ?delimiter.