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 Schurken JavaScript (die von Angreifern auf eine Website gepflanzt werden, z. B. durch die Verwendung von Werbung), AJAX-Anfragen in Ihrem Namen stellen. Betrügerische AJAX-Anfragen könnten 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 es JavaScript nicht erlaubt, die Antwort anzuzeigen (oder darauf zuzugreifen), wenn ein Server nicht mit den richtigen Antwortheadern antwortet.

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

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-Anfrage gibt es in zwei Formen: eine einfache CORS-Anfrage oder eine Preflight-CORS-Anfrage.

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
Folgende HTTP-Header können der einfachen CORS-Anforderung manuell hinzugefügt werden:
- Accept
- Accept-Language
- Content-Language
- Content-Type
- DPR
- Downlink
- Save-Data
- Viewport-Width
- Width
Content-Type muss, sofern festgelegt, Folgendes sein:
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain

Preflight-CORS-Anforderung

Wenn die Anforderung JavaScript 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 zum Auslösen des Preflight-Anforderungsflusses geführt haben. Mit anderen Worten: Wenn die HTTP-Anforderung JavaScript einige Methoden/Header in der HTTP-Anforderung angegeben hat, für die eine Preflight-CORS-Anforderung erforderlich ist, fragt die Preflight-CORS-Anforderung die Ressource nach diesen Methoden/Headern 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 Flag `cloudGateCorsEnabled` in `cloudGateCorsSettings` aktivieren, wird das Feature in Ihrem Mandanten aktiviert, und Identitätsdomains erzwingen die Liste der zulässigen Ursprünge, die in `cloudGateCorsAllowedOrigins` definiert sind, sowie 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 Header der Ursprungsanforderung an. Der Wert des Ursprungsheaders wird mit dieser Liste abgeglichen. Wenn der Ursprung übereinstimmt, 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 "`-`" 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, genaues Protokoll, kein Port: `https://.oraclecloud.com` Jede Domain, genaues Protokoll, kein Port: `https://`
`cloudGateCorsAllowNullOrigin`	Boolesche Eigenschaft zur Unterstützung von Szenarios, bei 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 zu einem anderen Server umleitet. Der Browser übergibt einen "Null"-Ursprung, wenn er den Ursprung als "gepflegt" betrachtet. Zur Erhöhung der Sicherheit sind standardmäßig "null" Ursprünge nicht zulässig. Einige "null" Ursprünge sind gültig. Für Anwendungen, die den OpenID Connect-(OIDC-)Browserablauf der Identitätsdomain nutzen, werden "null" Ursprünge angezeigt, die an ihre Cloud Gate-Knoten gesendet werden. Wenn Cloud Gate zur Identitätsdomain umleitet, autorisieren Sie den Endpunkt, die OIDC-Browseranmeldung zu starten, und wenn die Identitätsdomain die Anforderung an Cloud Gate zurückleitet, 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 Starten der Konfiguration sicher, dass Sie die richtige Version des Cloud Gate haben. Frühere Versionen des Cloud Gate-Moduls haben CORS nicht unterstützt. Es wurde geschützten Anwendungen überlassen, um CORS zu unterstützen. Wenn die Einstellung isCorsAllowed im Web Tier Policy-Dokument mit true konfiguriert wurde, lässt Cloud Gate CORS-Anforderungen vor dem Flug bis zu geschützten 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 Ihren 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 einen der folgenden Schritte aus, um die CORS-Unterstützung zu aktivieren.
- Starten Sie den NGINX-Server manuell neu, oder laden Sie ihn neu.
- Warten Sie, bis der CORS-Einstellungscache von Cloud Gate abläuft. Dies kann standardmäßig bis zu eine Stunde dauern.
Im Folgenden werden die CORS-Antwortheader aufgeführt, die Cloud Gate je nach CORS-Anforderung zurückgibt.
- 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 Anforderungsworkflows für Cross-Origin Resource Sharing (CORS).

Einfacher CORS-Anforderungsworkflow

Die Anforderung wird durch Vorhandensein des Ursprungsanforderungsheaders als CORS-Anforderung identifiziert.
Falls erforderlich (z.B. Cacheablauf), werden die Cloud Gate-CORS-Einstellungen aus Identitätsdomains in IAM heruntergeladen.
Cloud Gate verarbeitet die Anforderung. Die Anforderung wird entweder abgelehnt oder an den Upstreamanwendungsserver weitergeleitet.
Bevor eine Antwort zurückgegeben wird, erzwingt Cloud Gate CORS gemäß den Cloud Gate-CORS-Einstellungen.
1. Cloud Gate stellt immer sicher, dass der Header für variable Antworten Teil der Antwort ist - und den Header "Ursprung" enthält. Dies gilt auch für Nicht-CORS-Anforderungen.
2. Wenn cloudGateCorsEnabled den Wert false hat, wird die Verarbeitung hier gestoppt. Die Antwort 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 von der Antwort entfernt, und die Verarbeitung endet.
4. Der Access-Control-Allow-Origin-Antwortheader wird dem Wert des Ursprungsanforderungsheaders hinzugefügt und konfiguriert.
5. Der Access-Control-Allow-Credentials-Antwortheader 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. Die 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 durch Vorhandensein des Ursprungsanforderungsheaders als CORS-Anforderung identifiziert.
Falls erforderlich (z.B. Cacheablauf), werden die Cloud Gate-CORS-Einstellungen aus Identitätsdomains in IAM heruntergeladen.
Die Anforderung wird von der OPTIONS-Methode und dem Anforderungsheader Access-Control-Request-Method zusätzlich zum Anforderungsheader für den Ursprung als Preflight-CORS-Anforderung identifiziert.
Wenn cloudGateCorsEnabled true ist, kann die Anforderung an den Upstreamanwendungsserver weitergeleitet werden, damit Anwendungen CORS implementieren können.
Wenn cloudGateCorsEnabled false ist, wird die alte isCorsAllowed Web Tier Policy-Einstellung weiterhin berücksichtigt - erst 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 Header "Variable Antwort" Teil der Antwort ist - und enthält den Header "Ursprung". Dies tritt auch bei nonCORS-Anforderungen auf.
2. Wenn cloudGateCorsEnabled den Wert false hat, wird die Verarbeitung hier gestoppt. Die Antwort 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 von der Antwort entfernt, und die Verarbeitung endet.
4. Der Access-Control-Allow-Origin-Antwortheader wird dem Wert des Ursprungsanforderungsheaders hinzugefügt und konfiguriert.
5. Der Access-Control-Allow-Credentials-Antwortheader wird zu true hinzugefügt und konfiguriert.
6. Wenn der Upstreamanwendungsserver den Access-Control-Allow-Methods-Antwortheader nicht hinzugefügt hat, erstellt Cloud Gate seinen Wert wie folgt:
  - Wenn der Antwortheader zulässig 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 Access-Control-Allow-Headers-Antwortheader 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 zum Höchstalterwert hinzugefügt und konfiguriert. Wenn der cloudGateCorsMaxAge-Wert null oder weniger ist, wird keine Aktion für den Access-Control-Max-Age-Antwortheader ausgeführt.
9. Der Access-Control-Expose-Headers-Antwortheader wird entfernt. Dies gilt nicht für Preflight-Antworten.
Cloud Gate gibt seine Antwort zurück.

Oracle Cloud Infrastructure - Dokumentation