View a markdown version of this page

Calcoli della firma per l'intestazione dell'autorizzazione: trasferimento del payload in più blocchi (caricamento in blocchi) (AWS Signature (versione 4) - Amazon Simple Storage Service
Calcolo della firma inizialeDefinizione del corpo del bloccoEsempio: oggetto PUT

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Calcoli della firma per l'intestazione dell'autorizzazione: trasferimento del payload in più blocchi (caricamento in blocchi) (AWS Signature (versione 4)

Come descritto inPanoramica di, quando si autenticano le richieste utilizzando l'Authorizationintestazione, è possibile caricare il payload in blocchi. È possibile inviare dati in blocchi di dimensioni fisse o variabili. Questa sezione descrive il processo di calcolo della firma nel caricamento in blocchi, come si crea il corpo del blocco e come funziona la firma ritardata nel momento in cui si carica per la prima volta il blocco e si invia la firma nel blocco successivo. La sezione di esempio (vediEsempio: oggetto PUT) mostra i calcoli delle firme e le Authorization intestazioni risultanti che puoi utilizzare come suite di test per verificare il codice.

Nota

Quando si trasferiscono dati in una serie di blocchi, è necessario effettuare una delle seguenti operazioni:

  • Specificate in modo esplicito la lunghezza totale del contenuto (lunghezza dell'oggetto in byte più metadati in ogni blocco) utilizzando l'intestazione HTTP. Content-Length A tale scopo, è necessario precalcolare la lunghezza totale del payload, inclusi i metadati inviati in ogni blocco, prima di iniziare la richiesta.

  • Specificate l'intestazione HTTP. Transfer-Encoding Se includi l'Transfer-Encodingintestazione e specifichi un valore diverso daidentity, devi omettere l'intestazione. Content-Length

Per tutte le richieste, è necessario includere l'x-amz-decoded-content-lengthintestazione, specificando la dimensione dell'oggetto in byte.

Ogni calcolo della firma del blocco include la firma del blocco precedente. Per iniziare, crei una firma iniziale utilizzando solo le intestazioni. La firma iniziale viene utilizzata nel calcolo della firma del primo blocco. Per ogni blocco successivo, si crea una firma in blocco che include la firma del blocco precedente. Pertanto, le firme dei blocchi vengono concatenate; ovvero, la firma del blocco n è una funzione F (blocco n, firma (blocco n-1)). Il concatenamento garantisce l'invio dei blocchi nell'ordine corretto.

Per eseguire un caricamento in blocchi, procedi come segue:

  1. Decidi la dimensione del blocco del payload. Ne hai bisogno quando scrivi il codice.

    La dimensione del blocco deve essere di almeno 8 KB. Consigliamo una dimensione del blocco di almeno 64 KB per prestazioni migliori. Questa dimensione del blocco si applica a tutti i blocchi tranne l'ultimo. L'ultimo blocco inviato può essere inferiore a 8 KB. Se il payload è piccolo e può essere contenuto in un blocco, può essere inferiore agli 8 KB.

  2. Crea la firma iniziale da includere nel primo blocco. Per ulteriori informazioni, consulta Calcolo della firma iniziale.

  3. Crea il primo blocco e trasmettilo in streaming. Per ulteriori informazioni, consulta Definizione del corpo del blocco.

  4. Per ogni blocco successivo, calcola la firma del blocco che include la firma precedente nella stringa che firmi, costruisci il blocco e invialo. Per ulteriori informazioni, consulta Definizione del corpo del blocco.

  5. Inviate l'ultimo blocco aggiuntivo, che è lo stesso degli altri blocchi nella costruzione, ma contiene zero byte di dati. Per ulteriori informazioni, consulta Definizione del corpo del blocco.

Calcolo della firma iniziale

Il diagramma seguente illustra il processo di calcolo della firma iniziale.

Il processo di calcolo della firma iniziale.

La tabella seguente descrive le funzioni mostrate nel diagramma. Per queste funzioni devi implementare il codice.

Funzione Description
Lowercase() Converte la stringa in minuscolo.
Hex() Codifica in base 16 minuscola.
SHA256Hash() Funzione hash crittografica Secure Hash Algorithm (SHA).
HMAC-SHA256() Calcola HMAC utilizzando l'algoritmo SHA256 con la chiave di firma fornita. Questa è la firma definitiva.
Trim() Rimuove eventuali spazi bianchi all'inizio o alla fine della stringa.
UriEncode()

L'URI codifica ogni byte. UriEncode() deve applicare le seguenti regole:

  • L'URI codifica ogni byte tranne i caratteri senza riserve: 'A'-'Z', 'a'-'z', '0'-'9', '-', ' . ','_' e '~'.

  • Il carattere di spazio è un carattere riservato e deve essere codificato come "%20" (e non come "+").

  • Ogni byte codificato in URI è formato da una '%' e dal valore esadecimale a due cifre del byte.

  • Le lettere nel valore esadecimale devono essere maiuscole, ad esempio "%1A".

  • Codifica la barra, '/', ovunque tranne nel nome della chiave dell'oggetto. Ad esempio, se il nome della chiave dell'oggetto è photos/Jan/sample.jpg, la barra nel nome della chiave non è codificata.

Importante

Le UriEncode funzioni standard fornite dalla piattaforma di sviluppo potrebbero non funzionare a causa delle differenze di implementazione e della relativa ambiguità nelle RFC sottostanti. Ti consigliamo di scrivere una UriEncode funzione personalizzata per assicurarti che la codifica funzioni.

Di seguito è riportata una funzione example UriEncode () in Java.

public static String UriEncode(CharSequence input, boolean encodeSlash) {
          StringBuilder result = new StringBuilder();
          for (int i = 0; i < input.length(); i++) {
              char ch = input.charAt(i);
              if ((ch >= 'A' && ch <= 'Z') || (ch >= 'a' && ch <= 'z') || (ch >= '0' && ch <= '9') || ch == '_' || ch == '-' || ch == '~' || ch == '.') {
                  result.append(ch);
              } else if (ch == '/') {
                  result.append(encodeSlash ? "%2F" : ch);
              } else {
                  result.append(toHexUTF8(ch));
              }
          }
          return result.toString();
      }

Per informazioni sul processo di firma, vedereCalcolo delle firme per l'intestazione di autorizzazione: trasferimento del payload in un unico blocco (AWS Signature (versione 4). Il processo è lo stesso, tranne per il fatto che la creazione di è CanonicalRequest diversa come segue:

  • Oltre alle intestazioni delle richieste che intendi aggiungere, devi includere le seguenti intestazioni:

    Header Description
    x-amz-content-sha256

    Questa intestazione è obbligatoria per tutte le richieste di AWS Signature Version 4. Imposta il valore su STREAMING-AWS4-HMAC-SHA256-PAYLOAD per indicare che la firma copre solo le intestazioni e che non è presente alcun payload.
    Content-Encoding

    Impostare il valore su aws-chunked.

    Amazon S3 supporta più valori di codifica dei contenuti. Puoi specificare la codifica dei contenuti personalizzata quando usi l'API di streaming Signature Version 4.

    Ad esempio:

    Content-Encoding : aws-chunked,gzip

    Amazon S3 memorizza l'oggetto risultante senza il aws-chunked valore nell'intestazione. content-encoding Se aws-chunked è l'unico valore che passi nell'content-encodingintestazione, S3 considera l'intestazione vuota e non restituisce questa content-encoding intestazione quando recuperi l'oggetto.

    x-amz-decoded-content-length Imposta il valore sulla lunghezza, in byte, dei dati da suddividere in blocchi, senza contare i metadati. Ad esempio, se stai caricando un file da 4 GB, imposta il valore su 4294967296. Questa è la dimensione grezza dell'oggetto da caricare (dati che desideri archiviare in Amazon S3).
    Content-Length

    Imposta il valore sulla dimensione effettiva del corpo HTTP trasmesso, che include la lunghezza dei dati (valore impostato perx-amz-decoded-content-length), più i metadati in blocchi. Ogni blocco contiene metadati, come la firma del blocco precedente. I calcoli dei blocchi sono descritti nella sezione seguente. Se si include l'Transfer-Encodingintestazione e si specifica un valore diverso daidentity, non è necessario includere l'Content-Lengthintestazione.

Invii il primo blocco con la firma iniziale. È necessario costruire il blocco come descritto nella sezione seguente.

Definizione del corpo del blocco

Tutti i blocchi includono alcuni metadati. Ogni blocco deve essere conforme alla seguente struttura:

string(IntHexBase(chunk-size)) + ";chunk-signature=" + signature + \r\n + chunk-data + \r\n

Dove:

  • IntHexBase()è una funzione che si scrive per convertire la dimensione di un blocco intero in formato esadecimale. Ad esempio, se la dimensione del blocco è 65536, la stringa esadecimale è «10000".

  • chunk-sizeè la dimensione, in byte, del blocco di dati, senza metadati. Ad esempio, se si carica un oggetto da 65 KB e si utilizza una dimensione del blocco di 64 KB, si caricano i dati in tre blocchi: il primo sarà 64 KB, il secondo 1 KB e l'ultimo blocco con 0 byte.

  • signaturePer ogni blocco, si calcola la firma utilizzando la seguente stringa da firmare. Per il primo blocco, si utilizza la firma iniziale come firma precedente.

    Il processo di calcolo della firma iniziale che mostra i vari componenti della stringa da firmare.

La dimensione dei dati del blocco finale che invii è 0, sebbene il corpo del blocco contenga ancora metadati, inclusa la firma del blocco precedente.

Esempio: oggetto PUT

È possibile utilizzare gli esempi in questa sezione come riferimento per controllare i calcoli delle firme nel codice. Prima di esaminare gli esempi, tenete presente quanto segue:

  • I calcoli delle firme in questi esempi utilizzano le seguenti credenziali di sicurezza di esempio.

    Parametro Valore
    AWSAccessKeyId AKIAIOSFODNN7EXAMPLE
    AWSSecretAccessKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

  • Tutti gli esempi utilizzano il timestamp della richiesta 20130524T000000Z (). Fri, 24 May 2013 00:00:00 GMT

  • Tutti examplebucket gli esempi utilizzano come nome del bucket.

  • Si presume che il bucket si trovi nella regione Stati Uniti orientali (Virginia settentrionale) e le credenziali Scope e i Signing Key calcoli vengono utilizzati us-east-1 come identificatore della regione. Per ulteriori informazioni consultare l'articolo relativo alle Regioni ed endpoint nel documento Riferimenti generali di Amazon Web Services.

  • Puoi utilizzare lo stile del percorso o le richieste di stile ospitate virtualmente. Gli esempi seguenti utilizzano richieste di stile ospitate virtualmente, ad esempio: 

    https://examplebucket.s3.amazonaws.com/photos/photo1.jpg

    Per ulteriori informazioni, consulta Virtual Hosting of Buckets nella Amazon Simple Storage Service User Guide.

L'esempio seguente invia una PUT richiesta per caricare un oggetto. I calcoli delle firme presuppongono quanto segue:

  • Stai caricando un file di testo da 65 KB e il contenuto del file è una stringa di un carattere composta dalla lettera «a».

  • La dimensione del blocco è 64 KB. Di conseguenza, il payload viene caricato in tre blocchi, 64 KB, 1 KB e l'ultimo blocco con 0 byte di dati in blocco.

  • L'oggetto risultante ha il nome della chiave. chunkObject.txt

  • La richiesta viene effettuata REDUCED_REDUNDANCY come classe di archiviazione aggiungendo l'intestazione della x-amz-storage-class richiesta.

Per informazioni sull'azione API, consulta. PutObject La sintassi generale della richiesta è la seguente: 

PUT /examplebucket/chunkObject.txt HTTP/1.1
Host: s3.amazonaws.com
x-amz-date: 20130524T000000Z 
x-amz-storage-class: REDUCED_REDUNDANCY
Authorization: SignatureToBeCalculated
x-amz-content-sha256: STREAMING-AWS4-HMAC-SHA256-PAYLOAD
Content-Encoding: aws-chunked
x-amz-decoded-content-length: 66560
Content-Length: 66824
<Payload>

I passaggi seguenti mostrano i calcoli delle firme.

  1. Firma iniziale: crea una stringa da firmare
    1. CanonicalRequest

      PUT
/examplebucket/chunkObject.txt

content-encoding:aws-chunked
content-length:66824
host:s3.amazonaws.com
x-amz-content-sha256:STREAMING-AWS4-HMAC-SHA256-PAYLOAD
x-amz-date:20130524T000000Z
x-amz-decoded-content-length:66560
x-amz-storage-class:REDUCED_REDUNDANCY

content-encoding;content-length;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-storage-class
STREAMING-AWS4-HMAC-SHA256-PAYLOAD

      Nella richiesta canonica, la terza riga è vuota perché nella richiesta non sono presenti parametri di interrogazione. L'ultima riga è la stringa costante fornita come valore del Payload con hash, che deve essere uguale al valore di. x-amz-content-sha256 header

    2. StringToSign

      AWS4-HMAC-SHA256
20130524T000000Z
20130524/us-east-1/s3/aws4_request
cee3fed04b70f867d036f722359b0b1f2f0e5dc0efadbc082b76c4c60e316455

      Nota

      Per informazioni su ciascuna riga della stringa da firmare, consulta il diagramma che spiega il calcolo della firma iniziale.

  2. SigningKey

    signing key = HMAC-SHA256(HMAC-SHA256(HMAC-SHA256(HMAC-SHA256("AWS4" + "<YourSecretAccessKey>","20130524"),"us-east-1"),"s3"),"aws4_request")

  3. Firma del seme

    4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9

  4. Intestazione di autorizzazione

    L'intestazione di autorizzazione risultante è la seguente:

    AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,SignedHeaders=content-encoding;content-length;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-storage-class,Signature=4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9

  5. Blocco 1: (65536 byte, con valore 97 per la lettera «a»)

    1. Stringa in blocchi da firmare:

      AWS4-HMAC-SHA256-PAYLOAD
20130524T000000Z
20130524/us-east-1/s3/aws4_request
4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
bf718b6f653bebc184e1479f1935b8da974d701b893afcf49e701f3e2f9f9c5a

      Nota

      Per informazioni su ogni riga della stringa da firmare, vedete il diagramma precedente che mostra i vari componenti della stringa da firmare (ad esempio, le ultime tre righe sono, previous-signaturehash(""), ehash(current-chunk-data)).

    2. Firma in blocchi:

      ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648

    3. Dati in blocco inviati:

      10000;chunk-signature=ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648
<65536-bytes>
  6. Chunk 2: (1024 byte, con valore 97 per la lettera 'a')

    1. Stringa in blocchi da firmare:

      AWS4-HMAC-SHA256-PAYLOAD
20130524T000000Z
20130524/us-east-1/s3/aws4_request
ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
2edc986847e209b4016e141a6dc8716d3207350f416969382d431539bf292e4a

    2. Firma in blocco:

      0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497

    3. Dati in blocco inviati:

      400;chunk-signature=0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497
<1024 bytes>
  7. Blocco 3: (dati a 0 byte)

    1. Stringa in blocchi da firmare:

      AWS4-HMAC-SHA256-PAYLOAD
20130524T000000Z
20130524/us-east-1/s3/aws4_request
0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

    2. Firma in blocco:

      b6c6ea8a5354eaf15b3cb7646744f4275b71ea724fed81ceb9323e279d449df9

    3. Dati in blocco inviati:

      0;chunk-signature=b6c6ea8a5354eaf15b3cb7646744f4275b71ea724fed81ceb9323e279d449df9