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. # POST-Richtlinie **Topics** + [Ablauf](#sigv4-HTTPPOSTExpiration) + [Übereinstimmung von Bedingungen](#sigv4-ConditionMatching) + [Bedingungen](#sigv4-PolicyConditions) + [Escape-Zeichen](#sigv4-HTTPPOSTEscaping) Die Richtlinie, die für authentifizierte Anfragen mithilfe von HTTP POST erforderlich ist, ist ein Base64-kodiertes Dokument, das in JavaScript Object Notation (JSON) geschrieben ist UTF-8 und Bedingungen festlegt, die die Anforderung erfüllen muss. Je nachdem, wie Sie Ihr Richtliniendokument entwerfen, können Sie die Zugriffsgranularität pro Upload, pro Benutzer, für alle Uploads oder nach anderen Designs steuern, die Ihren Anforderungen entsprechen. In diesem Abschnitt wird die POST-Richtlinie beschrieben. Ein Beispiel für Signaturberechnungen mithilfe der POST-Richtlinie finden Sie unter[Beispiel: Browser-Based Upload mit HTTP POST (Mit AWS Signatur (Version 4)](sigv4-post-example.md). **Anmerkung** Obwohl das Richtliniendokument optional ist, empfehlen wir dringend, eines zu verwenden, um zu kontrollieren, was in der Anfrage zulässig ist. Wenn Sie den Bucket öffentlich beschreibbar machen, haben Sie keinerlei Kontrolle darüber, welche Benutzer in Ihren Bucket schreiben können. Das Folgende ist ein Beispiel für ein POST-Richtliniendokument. ``` 1. { "expiration": "2007-12-01T12:00:00.000Z", 2. "conditions": [ 3. {"acl": "public-read" }, 4. {"bucket": "johnsmith" }, 5. ["starts-with", "$key", "user/eric/"], 6. ] 7. } ``` Die POST-Richtlinie enthält immer die `conditions` Elemente `expiration` und. Die Beispielrichtlinie verwendet zwei Typen für den Abgleich von Bedingungen (exakte Übereinstimmung und beginnt mit Übereinstimmung). In den folgenden Abschnitten werden diese Elemente beschrieben. ## Ablauf Das `expiration` Element gibt das Ablaufdatum und die Uhrzeit der POST-Richtlinie im ISO8601-GMT-Datumsformat an. `2013-08-01T12:00:00.000Z`Gibt beispielsweise an, dass die POST-Richtlinie nach Mitternacht GMT am 1. August 2013 nicht gültig ist. ## Übereinstimmung von Bedingungen In der folgenden Tabelle werden die Typen für den Abgleich von Bedingungen beschrieben, die Sie zur Angabe von POST-Richtlinienbedingungen verwenden können (wie im nächsten Abschnitt beschrieben). Obwohl Sie für jedes Formularfeld, das Sie im Formular angeben, mindestens eine Bedingung angeben müssen, können Sie komplexere Übereinstimmungskriterien erstellen, indem Sie mehrere Bedingungen für ein Formularfeld angeben. | Art der Übereinstimmung mit der Bedingung | Description | | --- | --- | | Genaue Übereinstimmung | Der Wert des Formularfelds muss mit dem angegebenen Wert übereinstimmen. In diesem Beispiel ist angegeben, dass die ACL auf „public-read“ gesetzt werden muss:
{"acl": "public-read" }

Dieses Beispiel zeigt eine alternative Möglichkeit, um anzuzeigen, dass die ACL auf „public-read“ gesetzt werden muss:
[ "eq", "$acl", "public-read" ]
| | Beginnt mit | Der Wert muss mit dem angegebenen Wert beginnen. Dieses Beispiel gibt an, dass der Objektschlüssel beginnen muss mit user/user1:
["starts-with", "$key", "user/user1/"]
| | Content-Types In einer Comma-Separated Liste übereinstimmend | Content-Types Werte für eine `starts-with` Bedingung, die Kommas enthalten, werden als Listen interpretiert. Jeder Wert in der Liste muss die Bedingung erfüllen, damit die gesamte Bedingung erfüllt ist. Zum Beispiel unter der folgenden Bedingung:
["starts-with", "$Content-Type", "image/"]

Der folgende Wert würde die Bedingung erfüllen:
"image/jpg,image/png,image/gif"

Der folgende Wert würde die Bedingung nicht erfüllen:
["image/jpg,text/plain"]
Andere Datenelemente als `Content-Type` werden unabhängig vom Vorhandensein von Kommas als Zeichenfolgen behandelt. | | Übereinstimmung mit beliebigem Inhalt | Um die POST-Richtlinie so zu konfigurieren, dass jeder Inhalt in einem Formularfeld zulässig ist, verwenden Sie den Befehl `starts-with` mit einem leeren Wert („“). In diesem Beispiel sind alle Werte zulässig für`success_action_redirect`:
["starts-with", "$success_action_redirect", ""]
| | Angabe von Bereichen | Trennen Sie bei Formularfeldern, die einen Bereich akzeptieren, die obere und untere Grenze durch ein Komma. Dieses Beispiel erlaubt eine Dateigröße von 1 bis 10 MiB:
["content-length-range", 1048576, 10485760]
| Die spezifischen Bedingungen, die in einer POST-Richtlinie unterstützt werden, werden unter beschrieben[Bedingungen](#sigv4-PolicyConditions). ## Bedingungen `conditions`In einer POST-Richtlinie handelt es sich um ein Array von Objekten, von denen jedes zur Validierung der Anforderung verwendet wird. Sie können diese Bedingungen verwenden, um einzuschränken, was in der Anfrage zulässig ist. Die vorstehenden Richtlinienbedingungen erfordern beispielsweise Folgendes: + In der Anfrage muss der `johnsmith` Bucket-Name angegeben werden. + Der Objektschlüsselname muss das `user/eric` Präfix haben. + Die Objekt-ACL muss auf gesetzt sein`public-read`. Jedes Formularfeld, das Sie in einem Formular angeben (außer`x-amz-signature`, `file``policy`, und Feldnamen, die ein `x-ignore-` Präfix haben), muss in der Liste der Bedingungen erscheinen. **Anmerkung** Alle Variablen im Formular werden vor der Validierung der POST-Richtlinie erweitert. Daher sollten alle Bedingungsübereinstimmungen anhand der erweiterten Formularfelder erfolgen. Angenommen, Sie möchten Ihren Objektschlüsselnamen auf ein bestimmtes Präfix (`user/user1`) beschränken. In diesem Fall setzen Sie das Schlüsselformularfeld auf`user/user1/${filename}`. Ihre POST-Richtlinie sollte `[ "starts-with", "$key", "user/user1/" ]` lauten (nicht eingeben`[ "starts-with", "$key", "user/user1/${filename}" ]`). Weitere Informationen finden Sie unter [Übereinstimmung von Bedingungen](#sigv4-ConditionMatching). Die Bedingungen für das Richtliniendokument werden in der folgenden Tabelle beschrieben. | Elementname | Description | | --- | --- | | acl | Gibt den ACL-Wert an, der beim Senden des Formulars verwendet werden muss.
Diese Bedingung unterstützt den exakten Abgleich und den Typ der `starts-with` Bedingungsübereinstimmung, die im folgenden Abschnitt beschrieben werden. | | bucket | Gibt den akzeptablen Bucket-Namen an.
Diese Bedingung unterstützt den exakt passenden Zuordnungstyp. | | content-length-range | Die zulässige Mindest- und Höchstgröße für den hochgeladenen Inhalt.
Diese `content-length-range` Bedingung unterstützt den Zuordnungstyp. | | Cache-Control`Content-Type`
`Content-Disposition`
`Content-Encoding`
`Expires` | REST-specific Überschriften. Weitere Informationen finden Sie unter [POST Object](RESTObjectPOST.md).
Diese Bedingung unterstützt den exakten Abgleich und den Typ der `starts-with` Bedingungsübereinstimmung. | | key | Der zulässige Schlüsselname oder ein Präfix des hochgeladenen Objekts.
Diese Bedingung unterstützt den exakten Abgleich und den Typ der `starts-with` Bedingungsübereinstimmung. | | success\_action\_redirect`redirect` | Die URL, zu der der Client nach einem erfolgreichen Upload umgeleitet wird.
Diese Bedingung unterstützt die exakte Übereinstimmung und den Typ der `starts-with` Bedingungsübereinstimmung. | | success\_action\_status | Der Statuscode, der nach erfolgreichem Upload an den Client zurückgegeben `success_action_redirect` wird, falls nicht angegeben.
Diese Bedingung unterstützt den exakten Abgleich. | | x-amz-algorithm | Der Signaturalgorithmus, der bei der Signaturberechnung verwendet werden muss. Für AWS Signature Version 4 lautet der Wert`AWS4-HMAC-SHA256`.
Diese Bedingung unterstützt den exakten Abgleich. | | x-amz-credential | Die Anmeldeinformationen, die Sie zur Berechnung der Signatur verwendet haben. Es enthält Informationen zur Zugriffsschlüssel-ID und zum Geltungsbereich, die die Region und den Dienst identifizieren, für den die Signatur gültig ist. Dabei sollte es sich um denselben Bereich handeln, den Sie bei der Berechnung des Signaturschlüssels für die Signaturberechnung verwendet haben.
Es handelt sich um eine Zeichenfolge der folgenden Form:
`{{}}/{{}}/{{}}/{{}}/aws4_request`
Beispiel:
` AKIAIOSFODNN7EXAMPLE/20130728/us-east-1/s3/aws4_request`
Für Amazon S3 lautet die AWS-Service-Zeichenfolge. `s3` Eine Liste der Amazon `aws-region` S3-Zeichenfolgen finden Sie unter [ Regionen und Endpunkte ](https://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region) im. *Allgemeine AWS-Referenz* Dies ist erforderlich, wenn der Anfrage ein POST-Richtliniendokument beigefügt ist.
Diese Bedingung unterstützt den exakten Abgleich. | | x-amz-date | Der Datumswert, der in der nach ISO8601 formatierten Zeichenfolge angegeben ist. Beispiel, `20130728T000000Z`. Das Datum muss mit dem Datum übereinstimmen, das Sie bei der Erstellung des Signaturschlüssels für die Signaturberechnung verwendet haben.
Dies ist erforderlich, wenn der Anfrage ein POST-Richtliniendokument beigefügt ist.
Diese Bedingung unterstützt den exakten Abgleich. | | x-amz-security-token | DevPay Amazon-Sicherheitstoken.
Für jede Anfrage, die Amazon verwendet, DevPay sind zwei `x-amz-security-token` Formularfelder erforderlich: eines für das Produkt-Token und eines für das Benutzer-Token. Daher müssen die Werte durch Kommata voneinander getrennt werden. Wenn beispielsweise das Benutzer-Token `eW91dHViZQ==` und das Produkt-Token lautet`b0hnNVNKWVJIQTA=`, setzen Sie den POST-Richtlinieneintrag auf:`{ "x-amz-security-token": "eW91dHViZQ==,b0hnNVNKWVJIQTA=" }`.
Weitere Informationen zu Amazon DevPay finden Sie unter [ Using DevPay ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingDevPay.html) im * Amazon Simple Storage Service-Benutzerhandbuch*. | | x-amz-meta-\* | User-specified Metadaten.
Diese Bedingung unterstützt den exakten Abgleich und den Typ der `starts-with` Bedingungsübereinstimmung. | | x-amz-\* | Weitere `x-amz-*` Header finden Sie unter POST-Objekt ()[POST Object](RESTObjectPOST.md).
Diese Bedingung unterstützt den exakten Abgleich. | **Anmerkung** Wenn Ihr Toolkit weitere Formularfelder hinzufügt (z. B. Flash-Adds`filename`), müssen Sie diese dem POST-Richtliniendokument hinzufügen. Wenn Sie diese Funktionalität steuern können, setzen Sie `x-ignore-` vor das Feld, sodass Amazon S3 die Funktion ignoriert und künftige Versionen davon unbeeinflusst lässt. ## Escape-Zeichen Zeichen, die in einem POST-Richtliniendokument maskiert werden müssen, werden in der folgenden Tabelle beschrieben. | Escape-Sequenz | Beschreibung | | --- | --- | | \\\\ | Umgekehrter Schrägstrich | | \\$ | Dollarsymbol | | \\b | Backspace | | \\f | Seitenvorschub | | \\n | Neue Zeile | | \\r | Zeilenumschaltung | | \\t | Horizontaler Tabulator | | \\V | Vertikaler Tabulator | | \\ u {{xxxx}} | Alle Unicode-Zeichen | Nachdem Sie nun mit Formularen und Richtlinien vertraut sind und wissen, wie das Signieren funktioniert, können Sie ein Beispiel für einen POST-Upload ausprobieren. Sie müssen den Code schreiben, um die Signatur zu berechnen. Das Beispiel enthält ein Beispielformular und eine POST-Richtlinie, mit der Sie Ihre Signaturberechnungen testen können. Weitere Informationen finden Sie unter [Beispiel: Browser-Based Upload mit HTTP POST (Mit AWS Signatur (Version 4)](sigv4-post-example.md).