Die Cross-Origin Resource Sharing (CORS) von Adobe Experience Manager erleichtert nicht AEM Webeigenschaften das Ausführen von clientseitigen Aufrufen an AEM, sowohl authentifiziert als auch nicht authentifiziert, um Inhalte abzurufen oder direkt mit AEM zu interagieren.
CORS-Konfigurationen werden in AEM als OSGi-Konfigurationsfabriken verwaltet, wobei jede Richtlinie als eine Instanz der Factory dargestellt wird.
http://<host>:<port>/system/console/configMgr > Adobe Granite Cross Origin Resource Sharing Policy
Adobe Granite Cross-Origin Resource Sharing Policy (com.adobe.granite.cors.impl.CORSPolicyImpl
)
Eine Richtlinie wird durch Vergleich der
Allowed Origin
mit dem Origin
AnforderungsheaderAllowed Paths
mit dem Anfragepfad.Es wird die erste Richtlinie verwendet, die diesen Werten entspricht. Wenn keine gefunden wird, wird jede CORS -Anfrage abgelehnt.
Wenn überhaupt keine Richtlinie konfiguriert ist, werden CORS-Anforderungen auch nicht beantwortet, da der Handler deaktiviert und daher effektiv verweigert wird - solange kein anderes Modul des Servers auf CORS antwortet.
"alloworigin" <origin> | *
origin
-Parameter, die URIs angeben, die auf die Ressource zugreifen können. Bei Anfragen ohne Anmeldeinformationen kann der Server * als Platzhalter angeben, sodass jeder Ursprung auf die Ressource zugreifen kann. Es wird absolut nicht empfohlen, Allow-Origin: *
in der Produktion zu verwenden, da es jeder fremden (d. h. Angreifer-) Website erlaubt, Anfragen zu stellen, die ohne CORS von Browsern streng verboten sind."alloworiginregexp" <regexp>
regexp
regulären Ausdrücke, die URIs angeben, die auf die Ressource zugreifen können. Reguläre Ausdrücke können zu unbeabsichtigten Übereinstimmungen führen, wenn sie nicht sorgfältig erstellt wurden, sodass ein Angreifer einen benutzerdefinierten Domänennamen verwenden kann, der auch mit der Richtlinie übereinstimmt. Es wird allgemein empfohlen, für jeden bestimmten Herkunfts-Hostnamen separate Richtlinien zu verwenden, alloworigin
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."allowedpaths" <regexp>
regexp
regulären Ausdrücke, die die Ressourcenpfade angeben, für die die Richtlinie gilt."exposedheaders" <header>
"maxage" <seconds>
seconds
, der angibt, wie lange die Ergebnisse einer Pre-Flight-Anfrage zwischengespeichert werden können."supportedheaders" <header>
header
, die angeben, welche HTTP-Header bei der eigentlichen Anfrage verwendet werden können."supportedmethods"
"supportscredentials" <boolean>
boolean
, der angibt, ob die Antwort auf die Anfrage dem Browser angezeigt werden kann oder nicht. Bei Verwendung als Teil einer Antwort auf eine Preflight-Anfrage gibt dies an, ob die eigentliche Anfrage mit Anmeldeinformationen erfolgen kann.Site 1 ist ein einfaches, anonym zugängliches schreibgeschütztes Szenario, bei dem Inhalte über GET-Anforderungen genutzt werden:
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:OsgiConfig"
alloworigin="[https://site1.com]"
alloworiginregexp="[]"
allowedpaths="[/content/site1/.*]"
exposedheaders="[]"
maxage="{Long}1800"
supportedheaders="[Origin,Accept,X-Requested-With,Content-Type,
Access-Control-Request-Method,Access-Control-Request-Headers]"
supportedmethods="[GET]"
supportscredentials="{Boolean}false"
/>
Site 2 ist komplexer und erfordert autorisierte und unsichere Anfragen:
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:OsgiConfig"
alloworigin="[https://site2.com]"
alloworiginregexp="[]"
allowedpaths="[/content/site2/.*,/libs/granite/csrf/token.json]"
exposedheaders="[]"
maxage="{Long}1800"
supportedheaders="[Origin,Accept,X-Requested-With,Content-Type,
Access-Control-Request-Method,Access-Control-Request-Headers,Authorization,CSRF-Token]"
supportedmethods="[GET,HEAD,POST,DELETE,OPTIONS,PUT]"
supportscredentials="{Boolean}true"
/>
Ab Dispatcher 4.1.1 können Antwortheader zwischengespeichert werden. Dies ermöglicht das Zwischenspeichern von CORS-Headern entlang der CORS-angeforderten Ressourcen, solange die Anfrage anonym ist.
Im Allgemeinen können dieselben Überlegungen zum Zwischenspeichern von Inhalten im Dispatcher auf das Zwischenspeichern von CORS-Antwort-Headern beim Dispatcher angewendet werden. Die folgende Tabelle definiert, wann CORS -Kopfzeilen (und damit CORS -Anforderungen) zwischengespeichert werden können.
zwischenspeicherbar | Umgebung | Authentifizierungsstatus | Erklärung |
---|---|---|---|
Nein | AEM Publish | Authentifiziert | Die Dispatcher-Zwischenspeicherung in der AEM-Autoreninstanz ist auf statische, nicht erstellte Assets beschränkt. Dadurch wird es schwierig und unmöglich, die meisten Ressourcen in der AEM-Autoreninstanz zwischenzuspeichern, einschließlich HTTP-Antwortheadern. |
Nein | AEM-Veröffentlichung | Authentifiziert | Vermeiden Sie das Zwischenspeichern von CORS-Headern bei authentifizierten Anforderungen. Dies steht im Einklang mit der allgemeinen Anleitung, authentifizierte Anforderungen nicht zwischenspeichern zu lassen, da es schwierig ist zu bestimmen, wie sich der Authentifizierungs-/Autorisierungsstatus des anfragenden Benutzers auf die bereitgestellte Ressource auswirkt. |
Ja | AEM-Veröffentlichung | Anonym | Anonyme Anfragen, die im Dispatcher zwischengespeichert werden können, können auch ihre Antwortheader zwischenspeichern, sodass zukünftige CORS-Anfragen auf den zwischengespeicherten Inhalt zugreifen können. Jede CORS-Konfigurationsänderung in AEM Publish muss von einer Invalidierung der betroffenen zwischengespeicherten Ressourcen gefolgt sein. Best Practices erfordern die Bereinigung des Dispatcher-Caches durch Code- oder Konfigurationsbereitstellungen, da es schwierig ist zu bestimmen, welche zwischengespeicherten Inhalte möglicherweise ausgeführt werden. |
Um das Zwischenspeichern von CORS-Headern zu ermöglichen, fügen Sie allen unterstützenden AEM Publish dispatcher.any-Dateien die folgende Konfiguration hinzu.
/cache {
...
/headers {
"Origin"
"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 Änderungen an der Datei dispatcher.any
vorgenommen haben.
Wahrscheinlich ist es erforderlich, den Cache vollständig zu löschen, um sicherzustellen, dass die Kopfzeilen bei der nächsten Anfrage nach einer /cache/headers
-Konfigurationsaktualisierung entsprechend zwischengespeichert werden.
Die Protokollierung ist unter com.adobe.granite.cors
verfügbar:
DEBUG
aktivieren, um Details darüber anzuzeigen, warum eine CORS-Anfrage abgelehnt wurdeTRACE
aktivieren, um Details zu allen Anforderungen anzuzeigen, die über den CORS-Handler laufen.Access-Control-Allow-Origin
-Kopfzeile jedoch in der Antwort fehlt, überprüfen Sie die Protokolle unter DEBUG in com.adobe.granite.cors
auf Ablehnungen./cache/headers
-Konfiguration auf dispatcher.any
angewendet wird und der Webserver erfolgreich neu gestartet wurde.