View a markdown version of this page

Signaturberechnungen für den Autorisierungs-Header: Übertragung der Nutzlast in einem einzigen Block (AWS Signatur (Version 4) - Amazon Simple Storage Service

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Signaturberechnungen für den Autorisierungs-Header: Übertragung der Nutzlast in einem einzigen Block (AWS Signatur (Version 4)

Wenn Sie den Authorization Header zur Authentifizierung von Anfragen verwenden, enthält der Header-Wert unter anderem eine Signatur. Die Signaturberechnungen variieren je nachdem, welche Wahl Sie für die Übertragung der Nutzlast () -Übersicht treffen. In diesem Abschnitt werden Signaturberechnungen erläutert, wenn Sie sich dafür entscheiden, die Nutzlast in einem einzigen Block zu übertragen. Der Beispielabschnitt (sieheBeispiele: Signaturberechnungen) zeigt Signaturberechnungen und daraus resultierende Authorization Header, die Sie als Testsuite zur Überprüfung Ihres Codes verwenden können.

Wichtig

Wenn Sie Nutzdaten in einem einzigen Block übertragen, können Sie optional wählen, den Nutzlast-Hash in die Signaturberechnungen einzubeziehen, der als signierte Nutzlast bezeichnet wird (wenn Sie ihn nicht angeben, gilt die Nutzlast als unsigniert). Das im folgenden Abschnitt beschriebene Signaturverfahren gilt für beide, beachten Sie jedoch die folgenden Unterschiede:

  • Option für signierte Nutzdaten — Sie beziehen den Payload-Hash bei der Erstellung der kanonischen Anfrage ein (dieser wird dann Teil von StringToSign, wie im Abschnitt zur Berechnung der Signatur erklärt). Sie geben auch denselben Wert wie den x-amz-content-sha256 Header-Wert an, wenn Sie die Anfrage an S3 senden.

  • Payload-Option ohne Vorzeichen — Sie geben die Literalzeichenfolge an, UNSIGNED-PAYLOAD wenn Sie eine kanonische Anfrage erstellen, und legen denselben Wert wie den x-amz-content-sha256 Header-Wert fest, wenn Sie die Anfrage an Amazon S3 senden.

Wenn Sie Ihre Anfrage an Amazon S3 senden, informiert Amazon S3 anhand des x-amz-content-sha256 Header-Werts, ob die Payload signiert ist oder nicht. Amazon S3 kann dann die Signatur entsprechend zur Überprüfung erstellen.

In beiden Fällen müssen Sie den x-amz-content-sha256 Header nicht als kanonischen Header angebenHashedPayload, da der x-amz-content-sha256 Header-Wert bereits Teil Ihres ist.

Berechnung einer Signatur

Um eine Signatur zu berechnen, benötigen Sie zunächst eine zu signierende Zeichenfolge. Anschließend berechnen Sie mithilfe eines Signaturschlüssels einen HMAC-SHA256 Hash der zu signierenden Zeichenfolge. Das folgende Diagramm veranschaulicht den Vorgang, einschließlich der verschiedenen Komponenten der Zeichenfolge, die Sie zum Signieren erstellen

Wenn Amazon S3 eine authentifizierte Anfrage erhält, berechnet es die Signatur und vergleicht sie dann mit der Signatur, die Sie in der Anfrage angegeben haben. Aus diesem Grund müssen Sie die Signatur mit derselben Methode berechnen, die von Amazon S3 verwendet wird. Der Vorgang, bei dem eine Anfrage zur Unterzeichnung in einer vereinbarten Form gestellt wird, wird als Kanonisierung bezeichnet.

AWS4-HMAC-SHA256 Diagramm des Signaturprozesses, das die kanonische Anfrage und die Schritte zur Signatur zeigt. StringToSign

In der folgenden Tabelle werden die im Diagramm dargestellten Funktionen beschrieben. Für diese Funktionen muss Code implementiert werden.

Funktion Description
Lowercase() Wandeln Sie die Zeichenfolge in Kleinbuchstaben um.
Hex() Kodierung in Kleinbuchstaben im Basis-16-Format.
SHA256Hash() Kryptografische Hash-Funktion des Secure Hash Algorithm (SHA).
HMAC-SHA256() Berechnet HMAC unter Verwendung des SHA256-Algorithmus mit dem bereitgestellten Signaturschlüssel. Dies ist die endgültige Signatur.
Trim() Entfernen Sie alle führenden oder nachgestellten Leerzeichen.
UriEncode()

URI-kodiert jedes Byte. UriEncode() muss die folgenden Regeln durchsetzen:

  • URI kodiert jedes Byte mit Ausnahme der nicht reservierten Zeichen: „A“–„Z“, „a“–„z“, „0“–„9“, „-“, „.“, „_“ und „~“.

  • Das Leerzeichen ist ein reserviertes Zeichen und muss als „%20“ (und nicht als „+“) codiert werden.

  • Jedes URI-codierte Byte besteht aus einem „%“ und dem zweistelligen Hexadezimalwert des Bytes.

  • Buchstaben im Hexadezimalwert müssen in Großbuchstaben geschrieben sein, zum Beispiel „%1A“.

  • Kodieren Sie den Schrägstrich „/“ überall außer im Objektschlüsselnamen. Wenn der Objektschlüsselname beispielsweise photos/Jan/sample.jpg lautet, wird der Schrägstrich im Schlüsselnamen nicht codiert.

Wichtig

Die von Ihrer Entwicklungsplattform bereitgestellten UriEncode Standardfunktionen funktionieren möglicherweise aufgrund von Unterschieden in der Implementierung und den damit verbundenen Mehrdeutigkeiten in den zugrunde liegenden RFCs nicht. Wir empfehlen Ihnen, Ihre eigene benutzerdefinierte UriEncode Funktion zu schreiben, um sicherzustellen, dass Ihre Codierung funktioniert.

Das Folgende ist eine Beispielfunktion 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(); }

Aufgabe 1: Erstellen einer kanonischen Anforderung

Dieser Abschnitt bietet einen Überblick über das Erstellen einer kanonischen Anfrage.

Im Folgenden finden Sie das kanonische Anforderungsformat, das Amazon S3 zur Berechnung einer Signatur verwendet. Damit die Signaturen übereinstimmen, müssen Sie eine kanonische Anfrage in diesem Format erstellen:

<HTTPMethod>\n <CanonicalURI>\n <CanonicalQueryString>\n <CanonicalHeaders>\n <SignedHeaders>\n <HashedPayload>

Wobei Folgendes gilt:

  • HTTPMethodist eine der HTTP-Methoden, zum Beispiel GET, PUT, HEAD und DELETE.

  • CanonicalURIist die URI-encoded Version der absoluten Pfadkomponente des URI — alles, was mit dem „/“ beginnt und auf den Domainnamen folgt, bis zum Ende der Zeichenfolge oder bis zum Fragezeichen ('?') wenn Sie Abfragezeichenfolgenparameter haben. Beim URI im folgenden Beispiel, /examplebucket/myphoto.jpg, handelt es sich um den absoluten Pfad und Sie codieren das "/" nicht im absoluten Pfad:

    http://s3.amazonaws.com/examplebucket/myphoto.jpg

    Anmerkung

    Sie normalisieren die URI-Pfade für Anfragen an Amazon S3 nicht. Beispielsweise haben Sie möglicherweise einen Bucket mit einem Objekt namens „my-object//example//photo.user“. Durch die Normalisierung des Pfads wird der Objektname in der Anfrage in „my- /photo.user“ geändert. object/example Dies ist ein falscher Pfad für dieses Objekt.

  • CanonicalQueryStringgibt die Parameter der URI-encoded Abfragezeichenfolge an. Sie geben URI-encode den Namen und die Werte einzeln ein. Sie müssen die Parameter in der kanonischen Abfragezeichenfolge außerdem alphabetisch nach Schlüsselnamen sortieren. Die Sortierung erfolgt nach der Codierung. Die Abfragezeichenfolge im folgenden URI-Beispiel lautetprefix=somePrefix&marker=someMarker&max-keys=20:

    http://s3.amazonaws.com/examplebucket?prefix=somePrefix&marker=someMarker&max-keys=20

    Die kanonische Abfragezeichenfolge lautet wie folgt (zur besseren Lesbarkeit wurden diesem Beispiel Zeilenumbrüche hinzugefügt):

    UriEncode("marker")+"="+UriEncode("someMarker")+"&"+ UriEncode("max-keys")+"="+UriEncode("20") + "&" + UriEncode("prefix")+"="+UriEncode("somePrefix")

    Wenn eine Anfrage auf eine Unterressource abzielt, ist der entsprechende Abfrageparameterwert eine leere Zeichenfolge („“). Der folgende URI identifiziert beispielsweise die ACL-Unterressource im examplebucket-Bucket:

    http://s3.amazonaws.com/examplebucket?acl

    Das ist CanonicalQueryString in diesem Fall wie folgt:

    UriEncode("acl") + "=" + ""

    Wenn der URI kein „?“ enthält, gibt es in der Anfrage keine Abfragezeichenfolge und Sie legen die kanonische Abfragezeichenfolge auf eine leere Zeichenfolge („“) fest. Sie müssen weiterhin das „\n“ einfügen.

  • CanonicalHeadersist eine Liste von Anforderungsheadern mit ihren Werten. Einzelne Header-Namens- und Wertpaare werden durch das Zeilenumbruchzeichen („\n“) getrennt. Header-Namen müssen in Kleinbuchstaben geschrieben sein. Sie müssen die Header-Namen alphabetisch sortieren, um die Zeichenfolge zu erstellen, wie im folgenden Beispiel gezeigt:

    Lowercase(<HeaderName1>)+":"+Trim(<value>)+"\n" Lowercase(<HeaderName2>)+":"+Trim(<value>)+"\n" ... Lowercase(<HeaderNameN>)+":"+Trim(<value>)+"\n"

    Die in diesem Beispiel verwendeten Lowercase()- und Trim()-Funktionen werden im vorangehenden Abschnitt beschrieben.

    Die CanonicalHeaders Liste muss Folgendes enthalten:

    • HTTP-host-Header.

    • Wenn der Content-MD5 Header in der Anfrage vorhanden ist, müssen Sie ihn der CanonicalHeaders Liste hinzufügen.

    • Alle x-amz-*-Header, die Sie in Ihre Anfrage aufnehmen möchten, müssen ebenfalls hinzugefügt werden. Wenn Sie beispielsweise temporäre Sicherheitsanmeldeinformationen verwenden, müssen Sie x-amz-security-token in Ihre Anfrage einschließen. Sie müssen diesen Header zur Liste von hinzufügenCanonicalHeaders.

    Anmerkung
    • Der x-amz-content-sha256 Header ist für alle AWS Signature Version 4-Anfragen erforderlich. Es stellt einen Hash der Anforderungsnutzlast bereit. Sie müssen den jedoch nicht x-amz-content-sha256 als kanonischen Header angeben, da S3 seinen Wert automatisch verwendet, um den in der Anfrage gesendeten Nutzlast-Hash zu berechnen.

    • Wenn keine Nutzdaten vorhanden sind, müssen Sie den Hash einer leeren Zeichenfolge bereitstellen.

    • Wenn Sie nicht möchten, dass S3 den Hash der Anfrage abgleicht, können Sie stattdessen die Literalzeichenfolge verwenden. "UNSIGNED-PAYLOAD"

    Im Folgenden finden Sie CanonicalHeaders Beispielzeichenfolgen. Die Header-Namen sind in Kleinbuchstaben geschrieben und sortiert.

    Beispiel Beispiel 1
    host:s3.amazonaws.com x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 x-amz-date:20130708T220855Z
    Beispiel Beispiel 2
    host:s3.amazonaws.com x-amz-content-sha256:UNSIGNED-PAYLOAD x-amz-date:20130708T220855Z
    Beispiel Beispiel 3
    host:s3.amazonaws.com x-amz-date:20130708T220855Z
    Anmerkung

    Für die Berechnung einer Autorisierungssignatur sind der Host-Header und alle x-amz-* Header, ausgenommenx-amz-content-sha256, erforderlich. Um Datenmanipulationen zu verhindern, sollten Sie jedoch in Betracht ziehen, alle Header in die Signaturberechnung einzubeziehen.

    Das Signieren des x-amz-content-sha256 Headers ist optional, da S3 seinen Wert bei der Berechnung des Nutzlast-Hashs der empfangenen Anfrage verwendet.

  • SignedHeadersist eine alphabetisch sortierte, durch Semikolons getrennte Liste von Anforderungsheadernamen in Kleinbuchstaben. Bei den Anforderungs-Headern in der Liste handelt es sich um dieselben Header, die Sie in die Zeichenfolge CanonicalHeaders eingeschlossen haben. In den vorherigen Beispielen wäre der Wert von wie folgt: SignedHeaders

    Beispiel Beispiele 1 und 2
    host;x-amz-content-sha256;x-amz-date
    Beispiel Beispiel 3
    host;x-amz-date
  • HashedPayloadist der Hexadezimalwert des SHA256-Hashs der Anforderungsnutzlast.

    Hex(SHA256Hash(<payload>)

    Wenn die Anfrage keine Nutzlast enthält, berechnen Sie einen Hash der leeren Zeichenfolge wie folgt:

    Hex(SHA256Hash(""))

    Der Hash gibt den folgenden Wert zurück:

    e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

    Wenn Sie beispielsweise ein Objekt mithilfe einer PUT-Anfrage hochladen, stellen Sie Objektdaten im Textkörper bereit. Wenn Sie ein Objekt mithilfe einer GET-Anforderung abrufen, berechnen Sie den leeren String-Hash.

Aufgabe 2: Erstellen einer zu signierenden Zeichenfolge

Dieser Abschnitt bietet einen Überblick über das Erstellen einer Zeichenfolge zum Signieren. Eine schrittweise Anleitung finden Sie unter Aufgabe 2: Erstellen Sie eine Zeichenfolge zum Signieren in Allgemeine AWS-Referenz.

Die zu signierende Zeichenfolge ist eine Verkettung der folgenden Zeichenfolgen:

"AWS4-HMAC-SHA256" + "\n" + timeStampISO8601Format + "\n" + <Scope> + "\n" + Hex(SHA256Hash(<CanonicalRequest>))

Die konstante Zeichenfolge AWS4-HMAC-SHA256 gibt den Hash-Algorithmus an, den Sie verwenden,. HMAC-SHA256 Das timeStamp ist die aktuelle UTC-Zeit im ISO 8601-Format (z. B.20130524T000000Z).

Scopebindet die resultierende Signatur an ein bestimmtes Datum AWS-Region, an und einen Dienst. Daher funktioniert Ihre resultierende Signatur nur in der bestimmten Region und für einen bestimmten Dienst. Die Signatur ist nach dem angegebenen Datum sieben Tage lang gültig.

date.Format(<YYYYMMDD>) + "/" + <region> + "/" + <service> + "/aws4_request"

Für Amazon S3 lautet die Servicezeichenfolges3. Eine Liste der region Zeichenfolgen finden Sie unter Regionen und Endpunkte im Allgemeine AWS-Referenz. Die Spalte Region in dieser Tabelle enthält die Liste der gültigen Region-Zeichenfolgen.

Der folgende Bereich beschränkt die resultierende Signatur auf die us-east-1 Region und Amazon S3.

20130606/us-east-1/s3/aws4_request

Anmerkung

Scopemuss dasselbe Datum verwenden, das Sie für die Berechnung des Signaturschlüssels verwenden, wie im folgenden Abschnitt beschrieben.

Aufgabe 3: Signatur berechnen

In AWS Signature Version 4 verwenden Sie Ihre AWS Zugangsschlüssel nicht zum Signieren einer Anfrage, sondern erstellen zunächst einen Signaturschlüssel, der auf eine bestimmte Region und einen bestimmten Dienst beschränkt ist.  Weitere Informationen zum Signieren von Schlüsseln finden Sie unter. Einführung in das Signieren von Anfragen

DateKey = HMAC-SHA256("AWS4"+"<SecretAccessKey>", "<YYYYMMDD>") DateRegionKey = HMAC-SHA256(<DateKey>, "<aws-region>") DateRegionServiceKey = HMAC-SHA256(<DateRegionKey>, "<aws-service>") SigningKey = HMAC-SHA256(<DateRegionServiceKey>, "aws4_request")

Anmerkung

In einigen Anwendungsfällen können Signaturschlüssel bis zu 7 Tage lang verarbeitet werden. Weitere Informationen finden Sie unter Ein Objekt mit anderen teilen.

Eine Liste der Region-Zeichenfolgen finden Sie unter Regionen und Endpunkte im Allgemeine AWS-Referenz.

Wenn Sie einen Signaturschlüssel verwenden, können Sie Ihre AWS Anmeldeinformationen an einem sicheren Ort aufbewahren. Wenn Sie beispielsweise mehrere Server haben, die mit Amazon S3 kommunizieren, teilen Sie den Signaturschlüssel mit diesen Servern; Sie müssen nicht auf jedem Server eine Kopie Ihres geheimen Zugriffsschlüssels aufbewahren. Der Signaturschlüssel ist bis zu sieben Tage gültig. Jedes Mal, wenn Sie den Signaturschlüssel berechnen, müssen Sie den Signaturschlüssel also mit Ihren Servern teilen. Weitere Informationen finden Sie unter Anfragen authentifizieren (AWS Signatur (Version 4).

Die endgültige Signatur ist der HMAC-SHA256 Hash der zu signierenden Zeichenfolge, wobei der Signaturschlüssel als Schlüssel verwendet wird.

HMAC-SHA256(SigningKey, StringToSign)

Eine schrittweise Anleitung zum Erstellen einer Signatur finden Sie unter Aufgabe 3: Eine Signatur erstellen im Allgemeine AWS-Referenz.

Beispiele: Signaturberechnungen

Sie können die Beispiele in diesem Abschnitt als Referenz verwenden, um die Signaturberechnungen in Ihrem Code zu überprüfen. Die in den Beispielen gezeigten Berechnungen verwenden die folgenden Daten:

  • Beispiel für Zugriffsschlüssel.

    Parameter Wert
    AWSAccessKeyId AKIAIOSFODNN7EXAMPLE
    AWSSecretAccessKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
  • Zeitstempel der Anfrage von 20130524T000000Z (). Fri, 24 May 2013 00:00:00 GMT

  • Name examplebucket des Buckets.

  • Es wird davon ausgegangen, dass sich der Bucket in der Region USA Ost (Nord-Virginia) befindet. Die Anmeldeinformationen Scope und die Signing Key Berechnungen werden us-east-1 als Regionsspezifizierer verwendet. Informationen zu anderen Regionen finden Sie unter Regionen und Endpunkte im Allgemeine AWS-Referenz.

  • Sie können Anfragen im Pfadstil oder im virtuellen Hosting-Stil verwenden. Die folgenden Beispiele zeigen, wie Sie beispielsweise eine Anfrage im Stil eines virtuellen Hostings signieren:

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

    Weitere Informationen finden Sie unter Virtuelles Hosting von Buckets im Amazon Simple Storage Service-Benutzerhandbuch.

Beispiel: GET-Objekt

Im folgenden Beispiel werden die ersten 10 Byte eines Objekts (test.txt) abgerufenexamplebucket. Weitere Hinweise zur API-Aktion finden Sie unter GetObject.

GET /test.txt HTTP/1.1 Host: examplebucket.s3.amazonaws.com Authorization: SignatureToBeCalculated Range: bytes=0-9 x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 x-amz-date: 20130524T000000Z

Da diese GET-Anfrage keinen Textinhalt bereitstellt, kann der x-amz-content-sha256 Wert entweder der Hash des leeren Anforderungstextes oder die Literalzeichenfolge "UNSIGNED-PAYLOAD" sein. Die folgenden Schritte zeigen Signaturberechnungen und die Konstruktion des Authorization Headers unter Verwendung des Hashs einer leeren Zeichenfolge.

  1. StringToSign
    1. CanonicalRequest

      GET /test.txt host:examplebucket.s3.amazonaws.com range:bytes=0-9 x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 x-amz-date:20130524T000000Z host;range;x-amz-content-sha256;x-amz-date e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

      In der kanonischen Anforderungszeichenfolge ist die letzte Zeile der Hash des leeren Anforderungstextes. Die dritte Zeile ist leer, da die Anfrage keine Abfrageparameter enthält.

    2. StringToSign

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

  2. SigningKey

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

  3. Signatur

    f0e8bdb87c964420e857bd35b5d6ed310bd44f0170aba48dd91039c6036bdb41

  4. Authorization-Header

    Der resultierende Authorization Header lautet wie folgt:

    AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,SignedHeaders=host;range;x-amz-content-sha256;x-amz-date,Signature=f0e8bdb87c964420e857bd35b5d6ed310bd44f0170aba48dd91039c6036bdb41

Beispiel: PUT-Objekt

Diese Beispiel-PUT-Anfrage erstellt ein Objekt (test$file.text) inexamplebucket. In diesem Beispiel wird Folgendes angenommen:

  • Sie fordern REDUCED_REDUNDANCY als Speicherklasse an, indem Sie den x-amz-storage-class Anforderungsheader hinzufügen. Informationen zu Speicherklassen finden Sie unter Speicherklassen im Amazon Simple Storage Service-Benutzerhandbuch.

  • Der Inhalt der hochgeladenen Datei ist eine Zeichenfolge. "Welcome to Amazon S3." Der Wert von x-amz-content-sha256 in der Anfrage basiert auf dieser Zeichenfolge.

Hinweise zur API-Aktion finden Sie unter PutObject.

PUT test$file.text HTTP/1.1 Host: examplebucket.s3.amazonaws.com Date: Fri, 24 May 2013 00:00:00 GMT Authorization: SignatureToBeCalculated x-amz-date: 20130524T000000Z x-amz-storage-class: REDUCED_REDUNDANCY x-amz-content-sha256: 44ce7dd67c959e0d3524ffac1771dfbba87d2b6b4b4e99e42034a8b803f8b072 <Payload>

Die folgenden Schritte zeigen Signaturberechnungen.

  1. StringToSign
    1. CanonicalRequest

      PUT /test%24file.text date:Fri, 24 May 2013 00:00:00 GMT host:examplebucket.s3.amazonaws.com x-amz-content-sha256:44ce7dd67c959e0d3524ffac1771dfbba87d2b6b4b4e99e42034a8b803f8b072 x-amz-date:20130524T000000Z x-amz-storage-class:REDUCED_REDUNDANCY date;host;x-amz-content-sha256;x-amz-date;x-amz-storage-class 44ce7dd67c959e0d3524ffac1771dfbba87d2b6b4b4e99e42034a8b803f8b072

      In der kanonischen Anfrage ist die dritte Zeile leer, da die Anfrage keine Abfrageparameter enthält. Der x-amz-content-sha256 kanonische Header kann optional signiert werden, da sein Nutzlast-Hash bereits am Ende der Anfrage bereitgestellt wird. Die letzte Zeile ist der Hash des Hauptteils, der mit dem x-amz-content-sha256 header Wert übereinstimmen sollte, der in der HTTP-Anfrage an S3 gesendet wurde.

    2. StringToSign

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

  2. SigningKey

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

  3. Signatur

    98ad721746da40c64f1a55b78f14c238d841ea1380cd77a1b5971af0ece108bd

  4. Authorization-Header

    Der resultierende Authorization Header lautet wie folgt:

    AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,SignedHeaders=date;host;x-amz-content-sha256;x-amz-date;x-amz-storage-class,Signature=98ad721746da40c64f1a55b78f14c238d841ea1380cd77a1b5971af0ece108bd

Beispiel: GET Bucket Lifecycle

Die folgende GET-Anforderung ruft die Lebenszykluskonfiguration von examplebucket ab. Hinweise zur API-Aktion finden Sie unter GetBucketLifecycleConfiguration.

GET ?lifecycle HTTP/1.1 Host: examplebucket.s3.amazonaws.com Authorization: SignatureToBeCalculated x-amz-date: 20130524T000000Z x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Da die Anfrage keinen Textinhalt bereitstellt, ist der x-amz-content-sha256 Header-Wert der Hash des leeren Anforderungstextes. Die folgenden Schritte zeigen Signaturberechnungen.

  1. StringToSign
    1. CanonicalRequest

      GET / lifecycle= host:examplebucket.s3.amazonaws.com x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 x-amz-date:20130524T000000Z host;x-amz-content-sha256;x-amz-date e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

      In der kanonischen Anfrage ist die letzte Zeile der Hash des leeren Anforderungstextes.

    2. StringToSign

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

  2. SigningKey

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

  3. Signatur

    fea454ca298b7da1c68078a5d1bdbfbbe0d65c699e0f91ac7a200a0136783543

  4. Authorization-Header

    Der resultierende Authorization Header lautet wie folgt:

    AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,SignedHeaders=host;x-amz-content-sha256;x-amz-date,Signature=fea454ca298b7da1c68078a5d1bdbfbbe0d65c699e0f91ac7a200a0136783543

Beispiel: Bucket abrufen (Objekte auflisten)

Das folgende Beispiel ruft eine Liste von Objekten aus dem examplebucket Bucket ab. Hinweise zur API-Aktion finden Sie unter ListObjects.

GET ?max-keys=2&prefix=J HTTP/1.1 Host: examplebucket.s3.amazonaws.com Authorization: SignatureToBeCalculated x-amz-date: 20130524T000000Z x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Da die Anfrage keinen Hauptteil bereitstellt, x-amz-content-sha256 ist der Wert von der Hash des leeren Anforderungstextes. Die folgenden Schritte zeigen Signaturberechnungen.

  1. StringToSign
    1. CanonicalRequest

      GET / max-keys=2&prefix=J host:examplebucket.s3.amazonaws.com x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 x-amz-date:20130524T000000Z host;x-amz-content-sha256;x-amz-date e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

      In der kanonischen Zeichenfolge ist die letzte Zeile der Hash des leeren Anforderungstextes.

    2. StringToSign

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

  2. SigningKey

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

  3. Signatur

    34b48302e7b5fa45bde8084f4b7868a86f0a534bc59db6670ed5711ef69dc6f7

  4. Authorization-Header

    Der resultierende Authorization Header lautet wie folgt:

    AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,SignedHeaders=host;x-amz-content-sha256;x-amz-date,Signature=34b48302e7b5fa45bde8084f4b7868a86f0a534bc59db6670ed5711ef69dc6f7