Mit CORS arbeiten

Cross-Origin Resource Sharing (CORS) ist ein Header-basiertes Protokoll, mit dem JavaScript in Ihrem Namen Anforderungen für den Zugriff auf Ressourcen in einer anderen Domain stellen kann. Konfigurieren Sie Cloud Gate so, dass es CORS aktiviert und CORS-Einstellungen für Cloud Gate erzwingt, das in App-Gateway- oder IAM-Identitätsdomains ausgeführt wird.

CORS verhindert, dass bösartige JavaScript (die von Angreifern in eine Website gepflanzt werden, z. B. durch Werbung) AJAX-Anfragen in Ihrem Namen stellt. Betrügerische AJAX-Anfragen können Geld von Ihrer Bank abheben oder Einkäufe in Ihrem Namen auf einer Online-Shopping-Website tätigen. Diese Anforderungen können erfolgreich sein, wenn Sie derzeit eine aktive Session mit diesen Sites haben. CORS schreibt vor, dass der Browser JavaScript die Antwort nicht anzeigen (oder darauf zugreifen kann), wenn ein Server nicht mit dem richtigen Satz von Antwortheadern antwortet.

Eine CORS-Anforderung wird ausgelöst, wenn JavaScript versucht, eine HTTP-Anforderung an eine andere zu senden:

Domain - Beispiel: site1.oraclecloud.com ruft oracle.com auf
subdomain - Beispiel: site1.oraclecloud.com ruft site7.oraclecloud.com auf
port - Beispiel: site1.oraclecloud.com ruft site1.oraclecloud.com:3030 auf
Protokoll - Beispiel: https://site1.oraclecloud.com ruft http://site1.oraclecloud.com auf

Eine CORS-Anforderung wird in zwei Formen bereitgestellt: eine einfache CORS-Anforderung oder eine Preflight-CORS-Anforderung.

Einfache CORS-Anforderung

Eine einfache CORS-Anforderung wird ausgeführt, wenn die JavaScript-Anforderung für eine Ressource in einer anderen Domain die folgenden Eigenschaften aufweist:

Die Methode ist eine der folgenden:
- GET
- POST
- HEAD
Die zulässigen HTTP-Header, die der einfachen CORS-Anforderung manuell hinzugefügt werden können, sind:
- Accept
- Accept-Language
- Content-Language
- Content-Type
- DPR
- Downlink
- Save-Data
- Viewport-Width
- Width
Wenn Content-Type festgelegt ist, muss Folgendes gelten:
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain

CORS-Anforderung vor dem Start

Wenn die JavaScript-Anforderung die Eigenschaften einer einfachen CORS-Anforderung nicht erfüllt, wird eine Preflight-CORS-Anforderung an die Ressource in der anderen Domain gesendet.

Die Preflight-CORS-Anforderung testet, ob die tatsächliche Anforderung an diese Ressource gesendet werden kann, indem bestimmte HTTP-Header in die Anforderung mit den Daten aufgenommen werden, die dazu geführt haben, dass der Preflight-Anforderungsfluss ausgelöst wurde. Mit anderen Worten: Wenn in der HTTP-Anforderung JavaScript einige Methoden/Header in der HTTP-Anforderung angegeben wurden, für die eine Preflight-CORS-Anforderung erforderlich war, fragt die Preflight-CORS-Anforderung die Ressource für diese Methode/Header ab, um zu prüfen, ob die Ressource eine solche domainübergreifende Anforderung akzeptiert.

Cloud Gate-CORS-Konfigurationseigenschaften und -Attribute

In der folgenden Tabelle werden die Cloud Gate-CORS-Konfigurationseigenschaften und -Attribute beschrieben.


CORS-Eigenschaft	Beschreibung
`cloudGateCorsEnabled`	Boolesche Eigenschaft zum Aktivieren der Cloud Gate-CORS-Unterstützung für den Mandanten. Diese Einstellung muss wie folgt konfiguriert werden: `true`. Wenn Sie das Kennzeichen `cloudGateCorsEnabled` in `cloudGateCorsSettings` aktivieren, wird das Feature auf Ihrem Mandanten aktiviert, und Identitätsdomains erzwingen die Liste der zulässigen Ursprünge, die in `cloudGateCorsAllowedOrigins` definiert sind, und eine globale Liste der zulässigen Ursprünge. Der Standard ist `false`. Best Practice Konfigurieren Sie `cloudGateCorsAllowedOrigins` gleichzeitig. Wenn diese Eigenschaft leer bleibt, sind alle CORS-Anforderungen nicht erfolgreich.
`cloudGateCorsAllowedOrigins`	Die Eigenschaft ist ein Zeichenfolgenarray, das die Liste der zulässigen CORS-Ursprünge enthält. Der Standardwert ist ein leeres Array. Jede CORS-Anforderung gibt ihre Quelle oder ihren Ursprung im Origin-Anforderungsheader an. Der Wert des Ursprungsheaders wird mit dieser Liste abgeglichen. Wenn der Ursprung abgeglichen ist, fügt Cloud Gate der Antwort die entsprechenden CORS-Header hinzu. Wenn der Ursprung nicht übereinstimmt, gibt Cloud Gate keine CORS-Antwortheader zurück. Dadurch wird die Antwort vom Browser abgelehnt. Zulässige CORS-Werte in der Eingabevorlage: Eintrag: `* \| <PROTOCOL>"://"<HOST><PORT>` `<PROTOCOL>`: `* \| http \| https` `<HOST>`: `[<DOMAIN>.]<DOMAIN>` `<DOMAIN>`: `< any alphanumerical character, * and - >` Eine `<DOMAIN>` kann nicht mit einem "`-`" beginnen oder enden. Jede `<DOMAIN>` kann ein Platzhalter sein. Der Platzhalter muss die gesamte Domain enthalten. Beispiel: `www..com` ist gültig, `www.racle.com` jedoch nicht. Verwenden Sie https://tools.ietf.org/html/rfc1123 als Referenz `<PORT>`: `<EMPTY> \| ":" <PORT_VALUE>` `<PORT_VALUE>`: `* \| <numerical characters>`. `<PORT_VALUE>` muss im Bereich von 1 bis 65535 liegen. Beispiele: Alles abgleichen: `` Genaue Übereinstimmung: `https://www.acme.com, https://www.acme.com:4443` Exakter Host/Protokoll, beliebiger Port: `https://www.google.com:` Exakter Host/Port, beliebiges Protokoll (HTTP oder HTTPS): `://www.acme.com, ://www.acme.com:8080` Subdomain, exaktes Protokoll, kein Port: `https://.oraclecloud.com` Jede Domain, genaues Protokoll, kein Port: `https://`
`cloudGateCorsAllowNullOrigin`	Boolesche Eigenschaft zur Unterstützung von Szenarios, in denen der Browser einen "Null"-Ursprung sendet. Diese Einstellung muss wie folgt konfiguriert werden: `true`. Der Standard ist `false`. Ein "Null"-Ursprung wird gesendet, wenn die CORS-Anforderung von einer Datei auf dem Computer eines Benutzers stammt oder wenn ein Server als Antwort auf eine CORS-Anforderung an einen anderen Server umleitet. Der Browser übergibt einen "null" Ursprung, wenn er den Ursprung als "behalten" betrachtet. Um die Sicherheit zu erhöhen, sind standardmäßig "null" Origins nicht zulässig. Einige "null" Ursprünge sind gültig. Anwendungen, bei denen die OpenID Connect-(OIDC-)Browserablaufanmeldung der Identitätsdomain verwendet wird, sehen "null" Ursprünge, die an ihre Cloud Gate-Knoten gesendet werden. Wenn Cloud Gate an die Identitätsdomain umleitet und den Endpunkt autorisiert, die OIDC-Browseranmeldung zu starten, und wenn die Identitätsdomain die Anforderung zurück an Cloud Gate umleitet, ist der Ursprung "null".
`cloudGateCorsMaxAge`	Eine Ganzzahl, die angibt, wie viele Sekunden der Client (Browser) eine Preflight-CORS-Antwort cachen kann.
`cloudGateCorsExposedHeaders`	Die Eigenschaft ist ein Zeichenfolgenarray, das die Antwortheader auflistet, die dem Antwortheader `Access-Control-Expose-Headers` hinzugefügt werden können. Der Standardwert ist ein leeres Array.

Cloud Gate-CORS-Einstellungen in Identitätsdomains konfigurieren

Cloud Gate erfordert, dass Sie die folgenden Einstellungen in Identitätsdomains für die Unterstützung von Cross-Origin Resource Sharing (CORS) konfigurieren.

Stellen Sie vor dem Start der Konfiguration sicher, dass Sie die richtige Version des Cloud Gate haben. Frühere Versionen des Cloud Gate-Moduls bieten keine Unterstützung für CORS. Es wurde den geschützten Anwendungen überlassen, um CORS zu unterstützen. Wenn die Einstellung isCorsAllowed im Web Tier Policy-Dokument auf true konfiguriert wurde, lässt Cloud Gate CORS-Anforderungen vor dem Start in geschützte Anwendungen zu.

Hinweis

Die mindestens erforderliche Cloud Gate-Version ist 21.1.2.

Verwenden Sie den Endpunkt /admin/v1/Settings/Settings, um die CORS-Einstellungen zu konfigurieren. Die Anforderung ist ein patch-Vorgang. Weitere Informationen finden Sie unter Einstellung aktualisieren.

Verwenden Sie diese Beispiel-Payload als Vorlage, um den Anforderungstext zu erstellen. Speichern Sie die Payload in einer Datei. Beispiel: /tmp/cors-settings.json. Bearbeiten Sie die Datei mit den Deployment-Details.

Beispiel-Payload.

   {
   "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
   "Operations": [{
    "op": "replace",
    "path": "cloudGateCorsSettings",
    "value": {
    "cloudGateCorsEnabled": true,
    "cloudGateCorsAllowNullOrigin": true,
    "cloudGateCorsAllowedOrigins": [ "https://app.my-server.com:8080", "https://*:*" ],
    "cloudGateCorsMaxAge: 60,
    "cloudGateCorsExposedHeaders": [ "x-custom-header", "x-my-app-header" ]
    }
    }]
   }

cURL-Beispielanforderung.

   # $AT is a previously generated Admin Access Token.
   # https://<IdentityDomainID>.identity.oraclecloud.com is an example URL 
   $ curl -X PATCH -H "Content-Type: application/scim+json" -H "Accept: application/json" -H "Authorization: Bearer $AT" "https://<domainURL>/admin/v1/Settings/Settings" --data @"/tmp/cors-settings.json"

Führen Sie eine der folgenden Aktionen aus, um CORS-Support zu aktivieren.
- Starten Sie den NGINX-Server manuell neu oder laden Sie ihn neu.
- Warten Sie, bis der Cloud Gate-CORS-Einstellungscache abläuft. Dieser Vorgang kann standardmäßig bis zu eine Stunde dauern.
Die folgenden CORS-Antwortheader werden je nach CORS-Anforderung von Cloud Gate zurückgegeben.
- Access-Control-Allow-Origin
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- Access-Control-Allow-Credentials
- Access-Control-Max-Age
- Access-Control-Expose-Headers

Einfache und Preflight-CORS-Anforderungsworkflows

Überblick über CORS-(Cross-Origin Resource Sharing-)Anforderungsworkflows.

Einfacher CORS-Anforderungsworkflow

Die Anforderung wird als CORS-Anforderung identifiziert, weil der Origin-Anforderungsheader vorhanden ist.
Falls erforderlich (z.B. Cacheablauf), werden die Cloud Gate-CORS-Einstellungen von Identitätsdomains in IAM heruntergeladen.
Cloud Gate verarbeitet die Anforderung. Die Anforderung wird entweder abgelehnt oder an den Upstream-Anwendungsserver weitergeleitet.
Bevor eine Antwort zurückgegeben wird, erzwingt Cloud Gate CORS gemäß der Definition in den Cloud Gate-CORS-Einstellungen.
1. Cloud Gate stellt immer sicher, dass der variable Antwortheader Teil der Antwort ist - und den "Ursprungs"-Header enthält. Dies gilt auch für Nicht-CORS-Anfragen.
2. Wenn cloudGateCorsEnabled false ist, wird die Verarbeitung hier gestoppt. Die Reaktion wird unverändert zurückgegeben.
3. Cloud Gate prüft, ob der Ursprung zulässig ist. Dabei wird die konfigurierte Liste der zulässigen Ursprünge verwendet.
  Wenn der Ursprung nicht zulässig ist, werden alle unterstützten CORS-Antwortheader aus der Antwort entfernt, und die Verarbeitung endet.
4. Der Antwortheader Access-Control-Allow-Origin wird dem Wert des Ursprungsanforderungsheaders hinzugefügt und konfiguriert.
5. Der Antwortheader Access-Control-Allow-Credentials wird zu true hinzugefügt und konfiguriert.
6. Die Access-Control-Expose-Headers ist für die Schnittmenge zwischen dem Wert cloudGateCorsExposedHeaders und der Liste der Header konfiguriert, die in der Antwort zurückgegeben werden.
7. Access-Control-Allow-Methods, Access-Control-Allow-Headers und Access-Control-Max-Age Response Headers werden aus der Antwort entfernt.
Cloud Gate gibt seine Antwort zurück.

Hinweis

Cloud Gate überschreibt die Header Access-Control-Allow-Origin und Access-Control-Allow-Credentials Response, wenn sie vom Upstreamanwendungsserver festgelegt werden.

CORS-Anforderungsworkflow vor dem Start

Die Anforderung wird als CORS-Anforderung identifiziert, weil der Origin-Anforderungsheader vorhanden ist.
Falls erforderlich (z.B. Cacheablauf), werden die Cloud Gate-CORS-Einstellungen von Identitätsdomains in IAM heruntergeladen.
Die Anforderung wird durch die OPTIONS-Methode und den Access-Control-Request-Method-Anforderungsheader zusätzlich zum Origin-Anforderungsheader als Preflight-CORS-Anforderung identifiziert.
Wenn cloudGateCorsEnabled true ist, kann die Anforderung an den Upstream-Anwendungsserver weitergeleitet werden, damit Anwendungen CORS implementieren können.
Wenn cloudGateCorsEnabled false ist, wird die alte Web Tier Policy-Einstellung isCorsAllowed noch berücksichtigt - kurz später in der Anforderungsverarbeitung.
Bevor die Antwort von Cloud Gate zurückgegeben wird, wird CORS gemäß den Cloud Gate-CORS-Einstellungen durchgesetzt.
1. Cloud Gate stellt immer sicher, dass der variable Antwortheader Teil der Antwort ist - und den "Ursprungs"-Header enthält. Dies gilt auch für nonCORS-Anforderungen.
2. Wenn cloudGateCorsEnabled false ist, wird die Verarbeitung hier gestoppt. Die Reaktion wird unverändert zurückgegeben.
3. Cloud Gate prüft, ob der Ursprung zulässig ist. Dabei wird die konfigurierte Liste der zulässigen Ursprünge verwendet.
  Wenn der Ursprung nicht zulässig ist, werden alle unterstützten CORS-Antwortheader aus der Antwort entfernt, und die Verarbeitung endet.
4. Der Antwortheader Access-Control-Allow-Origin wird dem Wert des Ursprungsanforderungsheaders hinzugefügt und konfiguriert.
5. Der Antwortheader Access-Control-Allow-Credentials wird zu true hinzugefügt und konfiguriert.
6. Wenn der Upstreamanwendungsserver den Antwortheader Access-Control-Allow-Methods nicht hinzugefügt hat, erstellt Cloud Gate seinen Wert wie folgt:
  - Wenn der Antwortheader "Antwort zulassen" in der Antwort enthalten ist, verwendet Cloud Gate seinen Wert.
  - Wenn der Access-Control-Request-Method-Anforderungsheader in der Anforderung gefunden wird, verwendet Cloud Gate seinen Wert.
7. Wenn der Upstreamanwendungsserver den Antwortheader Access-Control-Allow-Headers nicht hinzugefügt hat, verwendet Cloud Gate den Wert des Access-Control-Request-Headers-Anforderungsheaders in der Anforderung, sofern vorhanden.
8. Wenn cloudGateCorsMaxAge mit einem Wert größer als Null konfiguriert ist, wird der Access-Control-Max-Age-Antwortheader dem maximalen Alterswert hinzugefügt und konfiguriert. Wenn der Wert für cloudGateCorsMaxAge Null oder kleiner ist, wird keine Aktion für den Antwortheader Access-Control-Max-Age ausgeführt.
9. Der Antwortheader Access-Control-Expose-Headers wird entfernt. Es gilt nicht für Preflight-Antworten.
Cloud Gate gibt seine Antwort zurück.

Oracle Cloud Infrastructure - Dokumentation