V2-Signaturprozess

Wichtig: Auf dieser Seite wird Legacy-Material zum V2-Signaturprozess erläutert. Nutzer sollten stattdessen mit dem V4-Signaturprozess arbeiten.

Diese Seite bietet einen Überblick über signierte URLs bei Verwendung des V2-Signaturprozesses, eines Mechanismus zur Authentifizierung von Abfragestrings für Buckets und Objekte. Mit signierten URLs können Sie jedem, der über diese URL verfügt, einen zeitlich begrenzten Lese- oder Schreibzugriff gewähren, unabhängig davon, ob er ein Nutzerkonto besitzt.

Wichtig: Der Zugriff auf Ressourcen in Cloud Storage mit signierten URLs ist nur über XML API-Endpunkte möglich.

Komponenten des zu signierenden Strings

Wenn Sie eine signierte URL mit einem Programm erstellen, erstellt das Programm einen String, der signiert werden muss. Dieser String muss im Programm folgendermaßen definiert werden:

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

Die einzelnen Komponenten dieser Struktur werden in der folgenden Tabelle beschrieben:

Stringkomponente	Beispiel	Beschreibung
HTTP_Verb	GET	Erforderlich. HTTP-Verb, das in der signierten URL verwendet werden soll. Hinweis: Das HTTP-Verb POST wird in signierten URL-Strings nur wie oben angegeben unterstützt. Sie können POST verwenden, um signierte Richtliniendokumente zu erstellen. In diesen Dokumenten können die Eigenschaften der Objekte festgelegt werden, die in einen Bucket hochgeladen werden dürfen. Weitere Informationen hierzu finden Sie in der Dokumentation zu POST-Objekt.
Content_MD5	rmYdCNHKFXam78uCt7xQLw==	Optional: Der MD5-Digest-Wert in Base64. Wenn Sie diesen Wert in den String aufnehmen, muss der Client (in der Regel ein Browser) in seiner Anfrage diesen HTTP-Header mit demselben Wert senden.
Content_Type	text/plain	Nach Bedarf. Wenn Sie einen content-type angeben, muss der Client (Browser) in diesem HTTP-Header denselben Wert haben.
Expires	1388534400	Erforderlich. Zeitstempel (Sekunden seit der Unix-Epoche 00:00:00 UTC vom 1. Januar 1970) für den Ablauf der Signatur. Der Server lehnt alle Anfragen, die nach diesem Zeitstempel eingehen, sowie alle Anfragen, die nach der Rotation des Schlüssels zur Generierung der signierten URL empfangen wurden, ab. Aus Sicherheits- und Kompatibilitätsgründen mit dem V4-Signaturprozess sollten Sie Expires auf maximal eine Woche (604.800 Sekunden) in der Zukunft festlegen.
Canonicalized_Extension_Headers	x-goog-acl:public-read\nx-goog-meta-foo:bar,baz\n	Nach Bedarf. Der Server prüft, ob der Client in Anfragen mit der signierten URL korrekte Werte sendet. Informationen über die Erstellung kanonischer Header zur Signatur finden Sie unter Kanonische Erweiterungsheader.
Canonicalized_Resource	/bucket/objectname	Erforderlich. Die Ressource, zu der die URL führt. Weitere Informationen finden Sie unter Kanonische Ressourcen.

Hinweis: Abfragestringparameter wie response-content-disposition und response-content-type werden von der Signatur nicht überprüft. Wenn Sie einen Content-Disposition oder Content-Type in der Antwort erzwingen möchten, legen Sie diese Parameter in den Objektmetadaten fest.

Strings mit dem App Engine App Identity-Dienst signieren

Wenn Sie eine signierte URL mit einem Programm erstellen, können Sie den String entweder direkt in diesem Programm signieren oder extern in einer App Engine-Anwendung mit dem App Engine Identity-Dienst, der die Dienstkonto-Anmeldedaten von App Engine verwendet. Zum Beispiel haben Sie mit der Python App Identity API folgende Möglichkeiten:

• Verwenden Sie google.appengine.api.app_identity.sign_blob(), um die Byte Ihres Strings zu signieren und die Signature anzugeben, die Sie beim Zusammenstellen der signierten URL benötigen.

• Verwenden Sie google.appengine.api.app_identity.get_service_account_name(), um einen Dienstkontonamen abzurufen. Dies ist die GoogleAccessId, die Sie beim Zusammenstellen der signierten URL benötigen.

Unterstützung in anderen Sprachen finden Sie unter App Identity API for Java, Übersicht über die App Identity API for PHP und App Identity Go-Funktionen.

Der App Identity-Dienst rotiert die privaten Schlüssel beim Signieren der Blobs. Signierte URLs, die mit dem App Identity-Dienst erstellt werden, sind für mindestens eine Stunde gültig und eignen sich am besten für kurzlebigen Zugriff auf Ressourcen.

Kanonische Erweiterungsheader

Beim Erstellen einer signierten URL mit einem Programm generieren Sie die kanonischen Erweiterungsheader der Nachricht durch Verkettung aller (benutzerdefinierten) Erweiterungsheader, die mit x-goog- beginnen. Sie können jedoch keine einfache Verkettung vornehmen. Beachten Sie beim Erstellen der Header den folgenden Algorithmus:

1. Alle benutzerdefinierten Header-Namen müssen aus Kleinbuchstaben bestehen.

2. Sortieren Sie alle benutzerdefinierten Headernamen lexikografisch nach Codepunkt-Wert.

3. Sofern vorhanden, entfernen Sie die Header x-goog-encryption-key und x-goog-encryption-key-sha256. Diese Header enthalten vertrauliche Informationen und dürfen nicht in den zu signierenden String aufgenommen werden. Dennoch müssen diese Header in allen Anfragen enthalten sein, die die signierte URL nutzen.

4. Entfernen Sie doppelt vorkommende Headernamen, indem Sie einen Headernamen mit einer durch Kommas getrennten Liste von Werten erstellen. Achten Sie darauf, dass zwischen den Werten kein Leerzeichen vorhanden ist und dass die Reihenfolge der durch Kommas getrennten Liste der Reihenfolge entspricht, in der die Header in Ihrer Anfrage aufgeführt sind. Weitere Informationen finden Sie unter RFC 7230, Abschnitt 3.2.

5. Ersetzen Sie aufeinanderfolgende Leerzeichen und Zeilenumbrüche (CRLF oder LF) durch ein einzelnes Leerzeichen. Weitere Informationen zu aufeinanderfolgenden Leerzeichen finden Sie unter RFC 7230, Abschnitt 3.2.4..

6. Entfernen Sie alle Leerzeichen vor und nach dem Doppelpunkt, der auf den Headernamen folgt.

7. Fügen Sie jedem benutzerdefinierten Header einen Zeilenumbruch "\n" (U+000A) hinzu.

8. Verketten Sie alle benutzerdefinierten Header.

Wichtig: Beim Erstellen der kanonischen Erweiterungsheader des Abfragestrings muss sowohl der Headername als auch der Headerwert verwendet werden. Achten Sie darauf, alle Leerzeichen vor und nach dem Doppelpunkt zu entfernen, der den Namen und den Wert des Headers trennt. Beispiel: Wenn Sie den benutzerdefinierten Header x-goog-acl: private verwenden, ohne das Leerzeichen hinter dem Doppelpunkt zu entfernen, wird der Fehler 403 Forbidden zurückgegeben, weil die so generierte Anfragesignatur nicht der von Cloud Storage generierten Signatur entspricht.

Kanonische Ressourcen

Wenn Sie eine signierte URL mit einem Programm erstellen, generieren Sie die kanonische Ressource der Nachricht, indem Sie den Ressourcenpfad (Bucket, Objekt und Unterressource) verketten, auf den sich die Anfrage auswirkt. Beachten Sie beim Erstellen der Ressource Folgendes:

• Die kanonische Ressource ist der gesamte Teil, der dem Hostnamen folgt. Ist die Cloud Storage-URL beispielsweise https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg, ist die kanonische Ressource /example-bucket/cat-pics/tabby.jpeg.

• Wenn sich die Anfrage auf eine Unterressource wie ?cors bezieht, fügen Sie diese Unterressource mit dem Fragezeichen am Ende des Strings ein.

• Der HTTP-Anfragepfad muss exakt kopiert werden, d. h., die gesamte URL-Codierung (Prozentzeichen) muss in den String aufgenommen werden. Nehmen Sie nur Abfragestringparameter auf, die eine Unterressource (z. B. cors) kennzeichnen. Verwenden Sie keine Abfragestringparameter wie ?prefix, ?max-keys, ?marker und ?delimiter.