Processus de signature V2

Important : Cette page couvre les anciens documents liés au processus de signature V2. Il est recommandé aux utilisateurs d'utiliser plutôt le processus de signature V4.

Cette page présente les URL signées lors de la mise en œuvre du processus de signature V2, qui constitue un mécanisme d'authentification des chaînes de requête pour les buckets et les objets. Les URL signées sont un moyen de fournir un accès en lecture ou en écriture limité dans le temps à toute personne en possession de l'URL, que celle-ci dispose ou non d'un compte utilisateur.

Important : Les URL signées ne peuvent être utilisées que pour accéder aux ressources Cloud Storage via des points de terminaison de l'API XML.

Composants de la chaîne qui demande une signature

Lorsque vous créez une URL signée à l'aide d'un programme, celui-ci construit une chaîne qui sera signée. Cette chaîne doit être définie dans votre programme comme suit :

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

Les composants de cette structure sont décrits dans le tableau ci-dessous :

Composant de chaîne	Exemple	Description
HTTP_Verb	GET	Obligatoire. Verbe HTTP à utiliser avec l'URL signée. Remarque : Le verbe HTTP POST n'est pas accepté dans les chaînes d'URL signées, sauf indication contraire comme ci-dessus. Vous pouvez utiliser POST pour définir des documents de stratégie signés, qui spécifient les caractéristiques des objets pouvant être importés dans un bucket. Pour en savoir plus, consultez la documentation sur les objets POST.
Content_MD5	rmYdCNHKFXam78uCt7xQLw==	Facultatif. Valeur condensée MD5 en Base64. Si vous ajoutez ce contenu à la chaîne, le client (généralement un navigateur) doit fournir cet en-tête HTTP avec la même valeur dans sa requête.
Content_Type	text/plain	Au besoin. Si vous fournissez un en-tête Content-Type, le client (navigateur) doit fournir cet en-tête HTTP défini sur la même valeur.
Expires	1388534400	Obligatoire. Horodatage (exprimé en nombre de secondes écoulées depuis l'époque Unix, soit le 1er janvier 1970 00:00:00 UTC) à l'expiration de la signature. Le serveur rejette toutes les requêtes reçues après cet horodatage, ainsi que celles reçues après la rotation de la clé utilisée pour générer l'URL signée. Pour des raisons de sécurité et de compatibilité avec le processus de signature V4, vous devez définir le composant Expires pour qu'il corresponde au maximum à la semaine suivante (604 800 secondes).
Canonicalized_Extension_Headers	x-goog-acl:public-read\nx-goog-meta-foo:bar,baz\n	Au besoin. Le serveur vérifie que le client fournit des valeurs correspondantes dans les requêtes utilisant l'URL signée. Pour en savoir plus sur la création d'en-têtes canoniques pour la signature, consultez la section En-têtes d'extension canoniques.
Canonicalized_Resource	/bucket/objectname	Obligatoire. Ressource désignée dans l'URL. Pour en savoir plus, consultez la section Ressources canoniques.

Remarque : Les paramètres de chaîne de requête tels que response-content-disposition et response-content-type ne sont pas validés par la signature. Pour forcer un Content-Disposition ou un Content-Type dans la réponse, définissez ces paramètres dans les métadonnées de l'objet.

Signer des chaînes avec le service App Identity d'App Engine

Lorsque vous créez une URL signée à l'aide d'un programme, vous pouvez signer la chaîne depuis votre programme ou depuis une application App Engine au moyen du service App Engine Identity. Celui-ci utilise les identifiants du compte de service App Engine. Par exemple, avec l'API App Identity pour Python, vous pouvez :

• utiliser la fonction google.appengine.api.app_identity.sign_blob() pour signer les octets de la chaîne que vous avez créée, fournissant ainsi l'élément Signature dont vous avez besoin dans l'assemblage de l'URL signée ;

• utiliser la fonction google.appengine.api.app_identity.get_service_account_name() pour récupérer un nom de compte de service, qui est l'élément GoogleAccessId dont vous avez besoin dans l'assemblage de l'URL signée.

Pour savoir comment procéder dans d'autres langages de programmation, consultez les pages Présentation de l'API App Identity pour Java, Présentation de l'API App Identity pour PHP et Fonctions Go de l'API App Identity.

Le service App Identity fonctionne par rotation des clés privées lors de la signature des blobs. Les URL signées créées à l'aide du service App Identity ont une durée de validité d'environ une heure et sont donc de préférence utilisées pour les accès de courte durée aux ressources.

En-têtes d'extension canoniques

Lorsque vous créez une URL signée à l'aide d'un programme, vous construisez la partie sur les en-têtes d'extension canoniques du message en concaténant tous les en-têtes d'extension (personnalisés) qui commencent par x-goog-. Cependant, vous ne pouvez pas effectuer une concaténation simple. Gardez à l'esprit l'algorithme suivant lors de la création des en-têtes :

1. Tous les noms d'en-têtes personnalisés doivent être en minuscules.

2. Tous les en-têtes personnalisés doivent être classés par nom d'en-tête en appliquant un ordre de tri lexicographique aux valeurs de point de code.

3. Si les en-têtes x-goog-encryption-key et x-goog-encryption-key-sha256 sont présentés, supprimez-les. Ces en-têtes contiennent des informations sensibles qui ne doivent pas être incluses dans la chaîne de caractères à signer. Toutefois, ils sont obligatoires dans toutes les requêtes utilisant l'URL signée générée.

4. Éliminez les en-têtes en double en créant un nom d'en-tête avec une liste de valeurs séparées par une virgule. Assurez-vous qu'il n'y a pas d'espace entre les valeurs et que l'ordre de la liste correspond à l'ordre dans lequel les en-têtes apparaissent dans votre requête. Pour plus d'informations, consultez la section 3.2 du document RFC 7230.

5. Remplacez les espaces de fin de ligne ou les nouvelles lignes (CRLF ou LF) par un seul espace. Pour plus d'informations sur les espaces de fin de ligne, consultez la section 3.2.4 du document RFC 7230.

6. Supprimez tous les espaces autour des deux points qui apparaissent après le nom de l'en-tête.

7. Ajoutez une nouvelle ligne "\n" (U+000A) à chaque en-tête personnalisé.

8. Concaténez tous les en-têtes personnalisés.

Important : Vous devez utiliser à la fois le nom et la valeur de l'en-tête lorsque vous construisez la partie sur les en-têtes d'extension canoniques de la chaîne de requête. Veillez à supprimer tout espace entre les deux points qui séparent le nom et la valeur de l'en-tête. Par exemple, le fait d'utiliser l'en-tête personnalisé x-goog-acl: private sans supprimer l'espace après le signe deux-points renvoie une erreur 403 Forbidden, car la signature de requête que vous avez calculée ne correspond pas à la signature calculée par Cloud Storage.

Ressources canoniques

Lorsque vous créez une URL signée à l'aide d'un programme, vous construisez la partie relative aux ressources canoniques du message en concaténant le chemin d'accès à la ressource (bucket, objet et sous-ressource) sur lequel agit la requête. Tenez compte des éléments suivants lorsque vous créez la ressource :

• La ressource canonique est tout ce qui suit le nom d'hôte. Par exemple, si l'URL Cloud Storage est https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg, la ressource canonique est /example-bucket/cat-pics/tabby.jpeg.

• Si la requête est associée à une sous-ressource, telle que ?cors, ajoutez cette sous-ressource à la fin de la chaîne, en incluant le point d'interrogation.

• Veillez à copier littéralement le chemin de la requête HTTP, c'est-à-dire en incluant l'ensemble du codage d'URL (signes de pourcentage) dans la chaîne que vous créez. Veillez également à n'inclure que les paramètres de chaîne de requête qui désignent des sous-ressources (comme cors). Vous ne devez pas inclure de paramètres de chaîne de requête tels que ?prefix, ?max-keys, ?marker et ?delimiter.