Förstå resursdelning mellan ursprung (CORS)
Adobe Experience Manager Cross-Origin Resource Sharing (CORS) underlättar för icke-AEM webbegenskaper att göra anrop på klientsidan till AEM, både autentiserad och oautentiserad, för att hämta innehåll eller direkt interagera med AEM.
OSGI-konfigurationen som beskrivs i det här dokumentet räcker för att:
- Resursdelning från en källa på AEM Publish
- CORS åtkomst till AEM Author
Om CORS-åtkomst med flera ursprung krävs på AEM Publish, se den här dokumentationen.
Adobe Granite Cross-Origin Resource Sharing Policy OSGi configuration
CORS-konfigurationer hanteras som OSGi-konfigurationsfabriker i AEM, där varje princip representeras som en instans av fabriken.
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
)
Val av policy
En profil väljs genom att jämföra
Allowed Origin
med begärandehuvudetOrigin
- och
Allowed Paths
med begärandesökvägen.
Den första principen som matchar dessa värden används. Om ingen hittas nekas alla CORS-begäranden.
Om ingen princip är konfigurerad alls besvaras inte heller CORS-begäranden eftersom hanteraren är inaktiverad och därmed nekas - så länge ingen annan modul på servern svarar på CORS.
Principegenskaper
Allowed Origins
"alloworigin" <origin> | *
- Lista med
origin
parametrar som anger URI:er som kan komma åt resursen. För begäranden utan autentiseringsuppgifter kan servern ange * som jokertecken, vilket ger alla ursprung åtkomst till resursen. Du bör inte användaAllow-Origin: *
i produktionen eftersom alla externa webbplatser (dvs. angripare) kan göra förfrågningar som inte har CORS är strängt förbjudna i webbläsare.
Allowed Origins (Regexp)
"alloworiginregexp" <regexp>
- Lista med
regexp
reguljära uttryck som anger URI:er som kan komma åt resursen. Reguljära uttryck kan leda till oönskade matchningar om de inte byggs noggrant, vilket gör att en angripare kan använda ett anpassat domännamn som också matchar principen. Det rekommenderas i allmänhet att ha separata principer för varje specifikt ursprungligt värdnamn, medalloworigin
, även om det innebär upprepad konfiguration av de andra principegenskaperna. Olika ursprung tenderar att ha olika livscykler och krav, vilket medför en klar separation.
Allowed Paths
"allowedpaths" <regexp>
- Lista med
regexp
reguljära uttryck som anger resurssökvägar som principen gäller för.
Exposed Headers
"exposedheaders" <header>
- Lista med rubrikparametrar som anger vilka svarshuvuden som webbläsare har åtkomst till. För CORS-begäranden (inte preflight) kopieras dessa värden till svarshuvudet
Access-Control-Expose-Headers
om de inte är tomma. Värdena i listan (rubriknamn) är sedan tillgängliga för webbläsaren. Utan dessa rubriker är de inte läsbara av webbläsaren.
Maximum Age
"maxage" <seconds>
- En
seconds
-parameter som anger hur länge resultatet av en preflight-begäran kan cachelagras.
Supported Headers
"supportedheaders" <header>
- Lista med
header
parametrar som anger vilka rubriker för HTTP-begäran som kan användas när den faktiska begäran görs.
Allowed Methods
"supportedmethods"
- Lista med metodparametrar som anger vilka HTTP-metoder som kan användas när den faktiska begäran görs.
Supports Credentials
"supportscredentials" <boolean>
- En
boolean
som anger om svaret på begäran kan visas för webbläsaren eller inte. När det används som en del av ett svar på en begäran före flygning, anger detta om den faktiska begäran kan göras med hjälp av autentiseringsuppgifter eller inte.
Exempelkonfigurationer
Plats 1 är ett grundläggande, anonym, skrivskyddat scenario där innehåll konsumeras via GET begäranden:
{
"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"
]
}
Webbplats 2 är mer komplex och kräver godkännande och mutering (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 cachningsproblem och konfiguration dispatcher-caching-concerns-and-configuration
Från och med Dispatcher 4.1.1+ kan svarshuvuden cachelagras. Detta gör det möjligt att cachelagra CORS huvuden längs med de CORS begärda resurserna, så länge som begäran är anonym.
I allmänhet kan samma aspekter för cachelagring av innehåll i Dispatcher användas för att cachelagra CORS-svarshuvuden vid dispatcher. I följande tabell definieras när CORS huvuden (och därmed CORS förfrågningar) kan cachelagras.
Tillåt CORS-begäranderubriker
Om du vill tillåta att de begärda HTTP-begäranrubrikerna skickas till AEM för bearbetning, måste de tillåtas i Dispatcher-konfigurationens /clientheaders
.
/clientheaders {
...
"Origin"
"Access-Control-Request-Method"
"Access-Control-Request-Headers"
}
Cachelagra CORS-svarshuvuden
Om du vill tillåta cachelagring och visning av CORS-huvuden i cachelagrat innehåll lägger du till följande /cache /headers-konfiguration i den AEM Publish dispatcher.any
-filen.
/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"
}
...
}
...
}
Kom ihåg att starta om webbserverprogrammet när du har gjort ändringar i filen dispatcher.any
.
Det är troligt att cache-minnet behöver rensas helt för att säkerställa att rubrikerna cachas korrekt på nästa begäran efter en /cache/headers
-konfigurationsuppdatering.
Felsökning av CORS
Loggning är tillgänglig under com.adobe.granite.cors
:
- aktivera
DEBUG
för att se information om varför en CORS-begäran nekades - aktivera
TRACE
för att se information om alla begäranden som går genom CORS-hanteraren
Tips:
-
Återskapa XHR-begäranden manuellt med hjälp av bolla, men se till att kopiera alla rubriker och detaljer, eftersom var och en kan göra skillnad. I vissa webbläsarkonsoler kan kommandot bolla kopieras
-
Verifiera om begäran nekades av CORS-hanteraren och inte av autentiseringen, CSRF-tokenfilter, dispatcherfilter eller andra säkerhetslager
- Om CORS-hanteraren svarar med 200, men
Access-Control-Allow-Origin
-huvudet saknas i svaret, kan du kontrollera om loggarna innehåller nekanden under DEBUG icom.adobe.granite.cors
- Om CORS-hanteraren svarar med 200, men
-
Om skickarcachelagring av CORS begäranden är aktiverat
- Kontrollera att konfigurationen
/cache/headers
har tillämpats pådispatcher.any
och att webbservern har startats om - Kontrollera att cachen rensades korrekt efter ändringar i OSGi eller dispatcher.konfigurationer.
- Kontrollera att konfigurationen
-
vid behov, kontrollera om det finns autentiseringsuppgifter för begäran.