Wissenswertes zu CORS (Cross-Origin Resource Sharing) bei AEM

Dokumentation AEM AEM-Tutorials AEM Foundation-Tutorials

Letzte Aktualisierung: 27. März 2025

Gilt für:
Experience Manager 6.4
Experience Manager 6.5

Themen:
APIs

Erstellt für:

Fortgeschrittener
Entwickler

Die Ressourcenfreigabe zwischen verschiedenen Ursprüngen (Cross-Origin Resource Sharing, CORS) von Adobe Experience Manager ermöglicht AEM-fremden Web-Eigenschaften Client-seitige (authentifzierte und nicht authentifizierte) Aufrufe an AEM, um Inhalte abzurufen oder direkt mit AEM zu interagieren.

Die in diesem Dokument beschriebene OSGi-Konfiguration reicht für Folgendes aus:

Ressourcenfreigabe mit nur einem Ursprung in AEM Publish
CORS-Zugriff auf AEM Author

Wenn für AEM Publish ein CORS-Zugriff mit mehreren Usprüngen erforderlich ist, lesen Sie diese Dokumentation.

OSGi-Konfiguration der Adobe Granite-CORS-Richtlinie

CORS-Konfigurationen werden in AEM als OSGi-Konfigurations-Factorys verwaltet, wobei jede Richtlinie als eine Instanz der Factory dargestellt wird.

http://<host>:<port>/system/console/configMgr > Adobe Granite Cross Origin Resource Sharing Policy

OSGi-Konfiguration der Adobe Granite-CORS-Richtlinie

Adobe Granite Cross-Origin Resource Sharing Policy (com.adobe.granite.cors.impl.CORSPolicyImpl)

Richtlinienauswahl

Eine Richtlinie wird durch Vergleich von Folgendem ausgewählt:

Allowed Origin mit dem Origin-Anfrage-Header
Allowed Paths mit dem Anfragepfad

Es wird die erste Richtlinie verwendet, die diesen Werten entspricht. Wenn keine gefunden wird, wird jede CORS-Anfrage abgelehnt.

Wenn keine Richtlinie konfiguriert ist, werden CORS-Anfragen ebenfalls nicht beantwortet, da der Handler deaktiviert ist und daher effektiv abgelehnt wird – solange kein anderes Modul des Servers CORS antwortet.

Richtlinieneigenschaften

Zulässige Ursprünge

"alloworigin" <origin> | *
Liste der origin-Parameter, von denen URIs spezifiziert werden, die auf die Ressource zugreifen dürfen. Bei Anfragen ohne Anmeldeinformationen kann der Server * als Platzhalter verwenden, sodass jeder Ursprung auf die Ressource zugreifen kann. Es wird ausdrücklich davon abgeraten, Allow-Origin: * in der Produktion zu verwenden, da dies jeder fremden Website (d. h. jedem Angreifer) erlaubt, Anfragen zu stellen, die ohne CORS von Browsern streng verboten sind.

Zulässige Ursprünge (regulärer Ausdruck)

"alloworiginregexp" <regexp>
Liste der regulären regexp-Ausdrücke, die die URIs spezifzieren, die auf die Ressource zugreifen dürfen. Reguläre Ausdrücke können zu unbeabsichtigten Übereinstimmungen führen, wenn sie nicht sorgfältig erstellt wurden, sodass ein Angreifer einen benutzerdefinierten Domain-Namen verwenden kann, der auch mit der Richtlinie übereinstimmt. Es wird allgemein empfohlen, mittels alloworigin für jeden Ursprungs-Host-Namen separate Richtlinien zu verwenden, auch wenn dies eine wiederholte Konfiguration der anderen Richtlinieneigenschaften bedeutet. Verschiedene Ursprünge weisen in der Regel unterschiedliche Lebenszyklen und Anforderungen auf und profitieren somit von einer klaren Trennung.

Zulässige Pfade

"allowedpaths" <regexp>
Liste der regulären regexp-Ausdrücke, durch die die Ressourcenpfade spezifiziert werden, für die die Richtlinie gilt.

Verfügbare Header

"exposedheaders" <header>
Liste der Kopfzeilen-Parameter, die angeben, auf welche Antwort-Header Browser zugreifen dürfen. Bei CORS-Anfragen (keine Pre-Flight-Anfragen) werden diese Werte, sofern sie nicht leer sind, in den Antwort-Header Access-Control-Expose-Headers kopiert. Die Werte in der Liste (Kopfzeilennamen) werden dann dem Browser zugänglich gemacht. Andernfalls kann der Browser diese Kopfzeilen nicht lesen.

Maximales Alter

"maxage" <seconds>
Ein seconds-Parameter, der angibt, wie lange die Ergebnisse einer Pre-Flight-Anfrage zwischengespeichert werden können.

Unterstützte Header

"supportedheaders" <header>
Liste der header-Parameter, die angeben, welche HTTP-Anfrage-Header bei der eigentlichen Anfrage verwendet werden können.

Zulässige Methoden

"supportedmethods"
Liste der Methodenparameter, die angeben, welche HTTP-Methoden bei der eigentlichen Anfrage verwendet werden können.

Unterstützt Anmeldeinformationen

"supportscredentials" <boolean>
Ein boolean-Parameter, der angibt, ob die Antwort auf die Anfrage dem Browser angezeigt werden kann. Bei Verwendung als Teil einer Antwort auf eine Pre-Flight-Anfrage gibt dies an, ob die eigentliche Anfrage unter Verwendung von Anmeldeinformationen erfolgen kann.

Beispielkonfigurationen

Bei „Site 1“ handelt es sich um ein einfaches, anonym zugängliches, schreibgeschütztes Szenario, in dem Inhalte über GET-Anfragen genutzt werden:

{
  "supportscredentials":false,
  "exposedheaders":[
    ""
  ],
  "supportedmethods":[
    "GET",
    "HEAD"
  ],
  "alloworigin":[
    "http://127.0.0.1:3000",
    "https://site1.com"

  ],
  "maxage:Integer": 1800,
  "alloworiginregexp":[
    "http://localhost:.*"
    "https://.*\.site1\.com"
  ],
  "allowedpaths":[
    "/content/_cq_graphql/site1/endpoint.json",
    "/graphql/execute.json.*",
    "/content/site1/.*"
  ],
  "supportedheaders":[
    "Origin",
    "Accept",
    "X-Requested-With",
    "Content-Type",
    "Access-Control-Request-Method",
    "Access-Control-Request-Headers"
  ]
}

„Site 2“ ist komplexer und erfordert autorisierte und verändernde Anfragen (POST, PUT, DELETE):

{
  "supportscredentials":true,
  "exposedheaders":[
    ""
  ],
  "supportedmethods":[
    "GET",
    "HEAD"
    "POST",
    "DELETE",
    "PUT"
  ],
  "alloworigin":[
    "http://127.0.0.1:3000",
    "https://site2.com"

  ],
  "maxage:Integer": 1800,
  "alloworiginregexp":[
    "http://localhost:.*"
    "https://.*\.site2\.com"
  ],
  "allowedpaths":[
    "/content/site2/.*",
    "/libs/granite/csrf/token.json",
  ],
  "supportedheaders":[
    "Origin",
    "Accept",
    "X-Requested-With",
    "Content-Type",
    "Access-Control-Request-Method",
    "Access-Control-Request-Headers",
    "Authorization",
    "CSRF-Token"
  ]
}

Dispatcher – Überlegungen zur Zwischenspeicherung und Konfiguration

Ab Dispatcher 4.1.1 können Antwort-Header zwischengespeichert werden. Dies ermöglicht das Zwischenspeichern von CORS-Headern mit den von CORS angeforderten Ressourcen, solange die Anfrage anonym ist.

Im Allgemeinen gelten dieselben Überlegungen beim Zwischenspeichern von Inhalten im Dispatcher für das Zwischenspeichern von CORS-Antwort-Headern im Dispatcher. In der folgenden Tabelle wird definiert, wann CORS-Header (und somit CORS-Anfragen) zwischengespeichert werden können.

Zwischenspeicherbar

Umgebung

Authentifizierungsstatus

Erklärung

Nein

AEM Publish

Authentifiziert

Die Dispatcher-Zwischenspeicherung in AEM Author ist auf statische Assets ohne Authoring beschränkt. Dadurch wird die Zwischenspeicherung der meisten Ressourcen in AEM Author, einschließlich HTTP-Antwort-Headern, schwierig und unpraktisch.

Nein

AEM Publish

Authentifiziert

Vermeiden Sie das Zwischenspeichern von CORS-Headern bei authentifizierten Anfragen. Dies entspricht der allgemeinen Empfehlung, authentifizierte Anfragen nicht zwischenzuspeichern, da nicht mit Sicherheit bestimmt werden kann, wie sich der Authentifizierungs-/Autorisierungsstatus der oder des anfragenden Benutzenden auf die bereitgestellte Ressource auswirkt.

Ja

AEM Publish

Anonym

Bei anonymen Anfragen, die im Dispatcher zwischengespeichert werden können, können auch ihre Antwort-Header zwischengespeichert werden, sodass zukünftige CORS-Anfragen auf den zwischengespeicherten Inhalt zugreifen können. Jeder Änderung der CORS-Konfiguration in AEM Publish muss eine Invalidierung der betroffenen zwischengespeicherten Ressourcen folgen. Best Practices verlangen bei Code- oder Konfigurationsbereitstellungen, dass der Dispatcher-Cache geleert wird, da es schwierig ist zu bestimmen, welche zwischengespeicherten Inhalte möglicherweise betroffen sind.

Zulassen von CORS-Anfrage-Headern

Damit die erforderlichen HTTP-Anfrage-Header zur Verarbeitung in AEM durchgeleitet werden können, müssen sie in der /clientheaders-Konfiguration vom Dispatcher zugelassen werden.

/clientheaders {
   ...
   "Origin"
   "Access-Control-Request-Method"
   "Access-Control-Request-Headers"
}

Zwischenspeichern von CORS-Antwort-Headern

Um das Zwischenspeichern und Bereitstellen von CORS-Headern für zwischengespeicherte Inhalte zu ermöglichen, fügen Sie die folgende /cache-/headers-Konfiguration zur Datei dispatcher.any von AEM Publish hinzu.

/publishfarm {
    ...
    /cache {
        ...
        # CORS HTTP response headers
        # https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#the_http_response_headers
        /headers {
            ...
            "Access-Control-Allow-Origin"
            "Access-Control-Expose-Headers"
            "Access-Control-Max-Age"
            "Access-Control-Allow-Credentials"
            "Access-Control-Allow-Methods"
            "Access-Control-Allow-Headers"
        }
    ...
    }
...
}

Denken Sie daran, die Webserver-Anwendung neu zu starten, nachdem Sie die Datei dispatcher.any geändert haben.

Es ist wahrscheinlich erforderlich, den Cache vollständig zu leeren, um sicherzustellen, dass die Header bei der nächsten Anfrage nach einer /cache/headers-Konfigurationsaktualisierung ordnungsgemäß zwischengespeichert werden.

Fehlerbehebung bei CORS

Die Protokollierung ist unter com.adobe.granite.cors verfügbar:

Aktivieren Sie DEBUG, um Details zur Ablehnung einer CORS-Anfrage anzuzeigen.
Aktivieren Sie TRACE, um Details zu allen über den CORS-Handler laufenden Anfragen anzuzeigen.

Tipps:

Erstellen Sie mithilfe des curl-Befehls manuell XHR-Anforderungen. Achten Sie jedoch darauf, alle Header und Details zu kopieren, da jeder Header und jedes Detail einen Unterschied bewirken kann. In einigen Browser-Konsolen ist es zulässig, den curl-Befehl zu kopieren.
Überprüfen Sie, ob die Anfrage vom CORS-Handler und nicht vom Authentifizierungsvorgang, CSRF-Token-Filter, Dispatcher-Filter oder von anderen Sicherheitsschichten abgelehnt wurde.
- Wenn der CORS-Handler mit 200 antwortet, aber der Header Access-Control-Allow-Origin in der Antwort fehlt, überprüfen Sie die Protokolle unter DEBUG in com.adobe.granite.cors auf Ablehnungen.
Bei aktivierter Dispatcher-Zwischenspeicherung von CORS-Anfragen:
- Stellen Sie sicher, dass die /cache/headers-Konfiguration auf dispatcher.any angewendet und der Webserver erfolgreich neu gestartet wurde.
- Stellen Sie sicher, dass der Cache nach OSGi- oder dispatcher.any-Konfigurationsänderungen ordnungsgemäß geleert wurde.
Überprüfen Sie bei Bedarf, ob Authentifizierungs-Anmeldeinformationen für die Anfrage vorhanden sind.

Hilfsmaterialien

recommendation-more-help