Procedura di firma V2

Importante: questa pagina illustra il materiale precedente relativo alla procedura di firma V2. Consigliamo agli utenti di utilizzare la procedura di firma V4.

Questa pagina fornisce una panoramica degli URL firmati quando si utilizza il processo di firma V2, ovvero un meccanismo per l'autenticazione delle stringhe di query per bucket e oggetti. Gli URL firmati offrono un modo per concedere a chiunque accesso in lettura o scrittura a tempo limitato in possesso dell'URL, indipendentemente dal fatto che dispongano di un account utente o meno.

Importante: gli URL firmati possono essere utilizzati solo per accedere alle risorse in Cloud Storage tramite endpoint API XML.

Componenti della stringa che richiede la firma

Quando crei un URL firmato utilizzando un programma, quest'ultimo genera una stringa che verrà firmato. Questa stringa deve essere definita nel programma come:

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

I componenti che compongono questa struttura sono descritti nella seguente tabella:

Componente Stringa	Esempio	Descrizione
HTTP_Verb	GET	Obbligatorio. Il verbo HTTP da utilizzare con l'URL firmato. Nota: il verbo HTTP POST non è supportato nelle stringhe URL firmate, tranne che come indicato sopra. Puoi utilizzare POST per definire documenti di criteri firmati che specificano le caratteristiche degli oggetti che possono essere caricati in un bucket. Scopri di più nella documentazione sull'oggetto POST.
Content_MD5	rmYdCNHKFXam78uCt7xQLw==	(Facoltativo) Il valore digest MD5 in Base64. Se lo specifichi nella stringa, il client (di solito un browser) deve fornire l'intestazione HTTP con lo stesso valore nella richiesta.
Content_Type	text/plain	In base alle necessità. Se fornisci un content-type, il client (browser) deve fornire questa intestazione HTTP impostata sullo stesso valore.
Expires	1388534400	Obbligatorio. Si tratta del timestamp (rappresentato come il numero di secondi dall'epoca di Unix alle 00:00:00 UTC il 1° gennaio 1970) di scadenza della firma. Il server rifiuta tutte le richieste ricevute dopo questo timestamp, nonché tutte le richieste ricevute dopo che la chiave utilizzata per generare l'URL firmato viene ruotata. Per motivi di sicurezza e per la compatibilità con il processo di firma V4, devi impostare Expires in modo che corrisponda al massimo a 1 settimana (604800 secondi) nel futuro.
Canonicalized_Extension_Headers	x-goog-acl:public-read\nx-goog-meta-foo:bar,baz\n	In base alle necessità. Il server verifica che il client fornisca valori corrispondenti nelle richieste che utilizzano l'URL firmato. Per informazioni su come creare intestazioni canoniche per la firma, consulta la sezione Intestazioni di estensioni canoniche.
Canonicalized_Resource	/bucket/objectname	Obbligatorio. La risorsa a cui fa riferimento l'URL. Per ulteriori dettagli, consulta Risorse canoniche.

Nota: parametri della stringa di query come response-content-disposition e response-content-type non sono verificati dalla firma. Per forzare un valore Content-Disposition o Content-Type nella risposta, imposta questi parametri nei metadati dell'oggetto.

Firmare le stringhe con il servizio App Engine App Identity

Quando crei un URL firmato utilizzando un programma, puoi firmare la stringa dall'interno del programma o da un'applicazione App Engine utilizzando il servizio App Engine Identity, che utilizza le credenziali dell'account di servizio di App Engine. Ad esempio, utilizzando API Python App Identity, puoi:

• Usa google.appengine.api.app_identity.sign_blob() per firmare i byte da la stringa creata, fornendo il valore Signature necessario quando assemblare l'URL firmato.

• Usa google.appengine.api.app_identity.get_service_account_name() per recuperare il nome di un account di servizio, ovvero il GoogleAccessId di cui hai bisogno durante l'assemblaggio dell'URL firmato.

Per assistenza in altre lingue, vedi Panoramica dell'API App Identity per Java, Panoramica dell'API App Identity per PHP, e le funzioni App Identity Go.

Il servizio App Identity ruota le chiavi private quando firma i BLOB. URL firmati generati dal servizio App Identity sono validi per almeno un'ora e sono ideali per alle risorse di breve durata.

Intestazioni delle estensioni canoniche

Quando crei un URL firmato utilizzando un programma, crei la versione Parte del messaggio con le intestazioni delle estensioni concatenando tutte (personalizzate) che iniziano con x-goog-. Tuttavia, non puoi eseguire una semplice concatenazione. Durante la creazione delle intestazioni, tieni presente il seguente algoritmo:

1. Rendi tutti i nomi delle intestazioni personalizzate in minuscolo.

2. Ordina tutte le intestazioni personalizzate in base al nome utilizzando un'ordinamento alfabetico in base al valore del punto di codice.

3. Se presenti, rimuovi x-goog-encryption-key e x-goog-encryption-key-sha256 intestazioni. Queste intestazioni contengono informazioni sensibili che non devono essere incluse in string-to-sign; tuttavia, queste intestazioni devono essere comunque utilizzate in richieste che usano l'URL firmato generato.

4. Elimina i nomi di intestazione duplicati creando un nome di intestazione con un elenco di valori separati da virgole. Assicurati che non vi siano spazi vuoti tra i valori e che l'ordine dei valori separato da virgole corrisponde all'ordine in cui le intestazioni vengono visualizzate nella richiesta. Per ulteriori informazioni, consulta la sezione 3.2 del documento RFC 7230.

5. Sostituisci gli spazi vuoti o i ritorni a capo (CRLF o LF) con un singolo spazio. Per ulteriori informazioni su come comprimere gli spazi vuoti, consulta la sezione 3.2.4 della RFC 7230.

6. Rimuovi gli spazi vuoti intorno al due punti visualizzato dopo il nome dell'intestazione.

7. Aggiungi una nuova riga "\n" (U+000A) a ogni intestazione personalizzata.

8. Concatena tutte le intestazioni personalizzate.

di Gemini Advanced.

Importante: devi utilizzare sia il nome che il valore dell'intestazione quando crei la porzione di intestazione delle estensioni canoniche della stringa di query. Assicurati di rimuovere eventuali uno spazio vuoto intorno ai due punti che separano il nome e il valore dell'intestazione. Ad esempio, utilizzando l'intestazione personalizzata x-goog-acl: private senza rimuovere lo spazio dopo i due punti un errore 403 Forbidden, perché la firma della richiesta calcolata non corrisponde e firma di Cloud Storage.

Risorse canoniche

Quando crei un URL firmato utilizzando un programma, crei la Parte del messaggio relativa alla risorsa canonicalizzata mediante la concatenazione della risorsa (bucket, oggetto e risorsa secondaria) su cui agisce la richiesta. Tieni presente quanto segue durante la creazione della risorsa:

• La risorsa canonica è tutto ciò che segue il nome host. Ad esempio: se l'URL di Cloud Storage è https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg, la risorsa canonica è /example-bucket/cat-pics/tabby.jpeg.

• Se la richiesta è limitata a una risorsa secondaria, ad esempio ?cors, aggiungi questa risorsa secondaria, incluso il punto interrogativo, alla fine della stringa.

• Assicurati di copiare il percorso della richiesta HTTP in modo letterale: ovvero, devi includere tutta la codifica dell'URL (segni di percentuale) nella stringa che crei. Inoltre, assicurati di includere solo la stringa di query parametri che designano le risorse secondarie (ad esempio cors). Non devi includere la stringa di query come ?prefix, ?max-keys, ?marker e ?delimiter.