CORS-Regeln konfigurieren
Fügen Sie per REST-API CORS-Regeln hinzu, damit Webanwendungen anderer Origins einen Bucket im Browser aufrufen können, und prüfen Sie, ob sie wirksam sind.
Fügen Sie einem Bucket CORS-Regeln hinzu, damit Skripte auf Webseiten von anderen Origins Anfragen an ihn senden können. Sie fügen Regeln über die REST-API hinzu und entfernen sie dort; die Konsole zeigt die Regeln eines Buckets an und ob sie wirksam sind.
Voraussetzungen
- Sie benötigen auf Abonnement- oder Projektebene die Rolle Besitzer oder Mitwirkender oder eine benutzerdefinierte Rolle mit der Zugriffsebene Verwalten für Block & Object Storage.
- Sie benötigen ein API-Token mit dem Bereich
storage:writein der UmgebungsvariablenPC_TOKEN. Siehe Dienstkonten und API-Tokens und Mit API-Tokens authentifizieren. - Sie benötigen die ID des Buckets: Kopieren Sie auf der Registerkarte Übersicht des Buckets den Wert Bucket-ID.
- Sie benötigen die ID Ihres Projekts. Siehe ID eines Projekts ermitteln.
So werden CORS-Regeln angewendet
Der Object Store verwaltet eine CORS-Richtlinie pro Bucket, daher führt die Plattform alle Regeln eines Buckets in dieser Richtlinie zusammen:
- Erlaubte Origins sind die Origins aller Regeln zusammen.
- Freigegebene Header, also die Antwort-Header, die Browser-Skripte lesen können, sind die Header aller Regeln zusammen.
- Max-Age, also wie lange ein Browser eine Preflight-Antwort zwischenspeichern darf, ist der längste Wert aller Regeln.
Ein Bucket ohne CORS-Regeln hat keine eigene CORS-Richtlinie.
Regelfelder
| Feld | Regeln |
|---|---|
origins | Mindestens einer. Jeder Origin ist * für einen beliebigen Origin oder ein exaktes scheme://host mit optionalem :port, z. B. https://app.example. Verwenden Sie nur ASCII, und schreiben Sie internationalisierte Domainnamen in Punycode. Kein Pfad, kein Platzhalter im Host, kein Benutzername oder Passwort und keine Leerzeichen. Origins werden in Kleinbuchstaben gespeichert, und der Object Store vergleicht sie exakt. |
methods | Mindestens eine, z. B. GET oder PUT. |
headers | Die Antwort-Header, die Browser-Skripte lesen können, z. B. ETag. Jeder Eintrag ist ein Header-Name oder *. Kann leer sein. |
maxAgeSeconds | 0 oder mehr. Wie lange ein Browser eine Preflight-Antwort zwischenspeichern darf, in Sekunden. |
Ein Bucket kann bis zu 100 CORS-Regeln haben. Die zusammengeführte Liste der Origins und die zusammengeführte Liste der freigegebenen Header müssen jeweils in das Limit des Object Stores für einen Metadatenwert passen; eine Regel, die es überschreiten würde, wird abgelehnt, und der Fehler nennt das Limit in Bytes.
CORS-Regel hinzufügen
Senden Sie die Regel an die Konfigurationsregeln des Buckets:
curl -X POST "https://<api-host>/api/v1/scopes/<project-id>/storage/buckets/<bucket-id>/configuration-rules" \
-H "Authorization: Bearer $PC_TOKEN" \
-H "Idempotency-Key: $(uuidgen)" \
-H "Content-Type: application/json" \
-d '{"type":"cors","cors":{"origins":["https://app.example"],"methods":["GET","PUT"],"headers":["ETag"],"maxAgeSeconds":3600}}'<api-host>: der Hostname der API. Siehe URL-Struktur.<project-id>: die ID des Projekts, das den Bucket enthält.<bucket-id>: die ID des Buckets.
Prüfen Sie die Antwort. Eine erfolgreiche Anfrage gibt 201 Created mit der neuen Regel zurück, einschließlich ihrer id:
{"id":"<rule-id>","bucketId":"<bucket-id>","type":"cors","cors":{"id":"<rule-id>","origins":["https://app.example"],"methods":["GET","PUT"],"headers":["ETag"],"maxAgeSeconds":3600},"lifecycle":null,"replication":null}Senden Sie für jede Regel einen Idempotency-Key-Header mit einem neuen Wert, wie im Beispiel. Wenn Sie eine Anfrage mit demselben Schlüssel und demselben Anfrage-Body wiederholen, gibt die API die Regel zurück, die die erste Anfrage erstellt hat, anstatt eine zweite hinzuzufügen. Ohne den Header fügt eine wiederholte Anfrage eine zweite Regel hinzu. Das Anfrageformat finden Sie unter POST/scopes/{scopeId}/storage/buckets/{bucketId}/configuration-rules.
Die Regel wird sofort gespeichert und im Hintergrund auf den Object Store angewendet. Ob sie wirksam ist, sehen Sie auf der Registerkarte CORS des Buckets.
Prüfen, ob die Regeln wirksam sind
Wechseln Sie in der Konsole zu SpeicherObjektspeicher, und wählen Sie den Namen des Buckets aus.
Wählen Sie die Registerkarte CORS aus.
Die Registerkarte listet für jede Regel Erlaubte Origins, Freigegebene Header und Max-Age auf. Über der Liste zeigt eine Zeile den Status der letzten Änderung an:
| Status | Bedeutung |
|---|---|
| Im Object Store wirksam. | Der Object Store enthält die aktuellen Regeln des Buckets. |
| Wird auf den Object Store angewendet… | Die Änderung wird angewendet. Die Plattform versucht es erneut, wenn der Object Store kurzzeitig nicht verfügbar ist. |
| Nicht angewendet — der Object Store behält seine bisherige CORS-Richtlinie: <reason> | Der Object Store hat die Änderung abgelehnt. Er behält seine bisherige CORS-Richtlinie. |
Über die API gibt GET/scopes/{scopeId}/storage/buckets/{bucketId} die Regeln in corsRules und den Status in corsApply.status zurück: pending, applied oder failed. corsApply ist null, wenn sich die Regeln des Buckets nie geändert haben.
CORS-Regel entfernen
Suchen Sie die id der Regel in corsRules:
curl "https://<api-host>/api/v1/scopes/<project-id>/storage/buckets/<bucket-id>" \
-H "Authorization: Bearer $PC_TOKEN"Löschen Sie die Regel:
curl -X DELETE "https://<api-host>/api/v1/scopes/<project-id>/storage/buckets/<bucket-id>/configuration-rules/<rule-id>" \
-H "Authorization: Bearer $PC_TOKEN"<rule-id>: die id der Regel.
Eine erfolgreiche Anfrage gibt 204 No Content zurück, und die Plattform wendet die verbleibenden Regeln auf den Object Store an. Wenn Sie die letzte Regel entfernen, wird die CORS-Richtlinie des Buckets entfernt. Siehe DELETE/scopes/{scopeId}/storage/buckets/{bucketId}/configuration-rules/{configurationRuleId}.
Um eine Regel zu ändern, entfernen Sie sie, und fügen Sie eine neue hinzu. Regeln können nicht bearbeitet werden.
Ergebnis
Browser-Anfragen von den erlaubten Origins erhalten die CORS-Header, die die zusammengeführte Richtlinie des Buckets festlegt.
Problembehandlung
| Antwort | Ursache | Lösung |
|---|---|---|
422 mit code VALIDATION_FAILED und field cors.origins | Ein Origin ist weder * noch ein exaktes scheme://host[:port] in ASCII. | Entfernen Sie den Pfad oder den Platzhalter, und schreiben Sie internationalisierte Namen in Punycode. |
422 mit field cors.headers | Ein Header-Eintrag ist weder ein einzelner Header-Name noch *. | Senden Sie einen Header-Namen pro Eintrag. |
422 mit details.reason cors_policy_too_large | Die zusammengeführten Origins oder Header würden das Limit des Object Stores überschreiten, das in details.limitBytes angegeben ist. | Entfernen Sie zuerst Origins, Header oder Regeln. |
409 mit code QUOTA_EXCEEDED | Der Bucket hat bereits 100 CORS-Regeln. | Entfernen Sie Regeln, oder fassen Sie ihre Origins in weniger Regeln zusammen. |
409 mit code CONFLICT | Der Bucket wird erstellt oder gelöscht, oder er befindet sich in einem Fehlerzustand. | Wenn der Bucket erstellt wird, warten Sie, bis seine Erstellung abgeschlossen ist. Ein Bucket, der gelöscht wird oder sich in einem Fehlerzustand befindet, kann keine neuen Regeln annehmen. |
422 mit details.reason lifecycle_not_supported oder replication_not_supported | Der type der Regel ist lifecycle oder replication. Die Plattform wendet diese Regeltypen nicht an. | Senden Sie nur CORS-Regeln. |
| Nicht angewendet — der Object Store behält seine bisherige CORS-Richtlinie: <reason> auf der Registerkarte CORS | Der Object Store hat die zusammengeführte Richtlinie abgelehnt. | Entfernen Sie die Regel, die Sie zuletzt hinzugefügt haben. Jede Änderung wendet den gesamten Regelsatz des Buckets erneut an. |