Cross-Origin Resource Sharing von Adobe Experience Manager (CORS) ermöglicht es nicht AEM Webeigenschaften, clientseitige Aufrufe an AEM durchzuführen, 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
Anfrage-HeaderAllowed Paths
mit dem Anfragepfad.Es wird die erste Richtlinie verwendet, die diesen Werten entspricht. Wenn keine gefunden wird, wird jede CORS Anfrage wird abgelehnt.
Wenn keine Richtlinie konfiguriert ist, CORS -Anfragen werden auch nicht beantwortet, da der -Handler deaktiviert ist und daher effektiv verweigert wird - solange kein anderes Modul des Servers auf CORS.
"alloworigin" <origin> | *
origin
Parameter zum Angeben von URIs, die auf die Ressource zugreifen können. Bei Anfragen ohne Anmeldeinformationen kann der Server * als Platzhalter verwenden, sodass jeder Ursprung auf die Ressource zugreifen kann. Die Verwendung von Allow-Origin: *
in der Produktion, 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ücken, 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 Herausgeber-Hostnamen separate Richtlinien zu verwenden, indem 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ücken, die die Ressourcenpfade angeben, für die die Richtlinie gilt."exposedheaders" <header>
"maxage" <seconds>
seconds
Parameter, der angibt, wie lange die Ergebnisse einer Pre-Flight-Anfrage zwischengespeichert werden können."supportedheaders" <header>
header
Parameter, die angeben, welche HTTP-Header bei der eigentlichen Anfrage verwendet werden können."supportedmethods"
"supportscredentials" <boolean>
boolean
Gibt an, 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, in dem Inhalte über verwendet werden. GET Anforderungen:
{
"supportscredentials":false,
"exposedheaders":[
""
],
"supportedmethods":[
"GET",
"HEAD",
"OPTIONS"
],
"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 mutierbare Anfragen (POST, PUT, DELETE):
{
"supportscredentials":true,
"exposedheaders":[
""
],
"supportedmethods":[
"GET",
"HEAD"
"POST",
"DELETE",
"OPTIONS",
"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"
]
}
Ab Dispatcher 4.1.1 können Antwortheader zwischengespeichert werden. Dies ermöglicht das Zwischenspeichern von CORS Kopfzeilen entlang der CORS-angeforderte 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. In der folgenden Tabelle wird definiert, wann CORS Header (und somit CORS -Anfragen) zwischengespeichert werden.
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 Publish | 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 Publish | 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 Änderung der CORS-Konfiguration bei der AEM-Veröffentlichung must gefolgt von einer Invalidierung der betroffenen zwischengespeicherten Ressourcen. 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.
/myfarm {
...
/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, Starten Sie die Webserver-Anwendung neu , nachdem Sie Änderungen an der dispatcher.any
-Datei.
Es ist wahrscheinlich erforderlich, den Cache vollständig zu löschen, um sicherzustellen, dass die Kopfzeilen bei der nächsten Anforderung nach einer /cache/headers
Konfigurationsaktualisierung.
Die Protokollierung ist unter verfügbar. com.adobe.granite.cors
:
DEBUG
, um Details zu erhalten, warum ein CORS Anfrage wurde abgelehntTRACE
, um Details zu allen Anfragen anzuzeigen, die über den CORS-Handler laufen.Access-Control-Allow-Origin
-Kopfzeile fehlt in der Antwort, überprüfen Sie die Protokolle unter auf Ablehnungen DEBUG in com.adobe.granite.cors
/cache/headers
-Konfiguration auf dispatcher.any
und der Webserver erfolgreich neu gestartet wurde