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:

  1. Resursdelning från en källa på AEM Publish
  2. 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 OSGi configuration

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ärandehuvudet Origin
  • 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ända Allow-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, med alloworigin, ä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.

Cacheable
Miljö
Autentiseringsstatus
Förklaring
Nej
AEM Publish
Autentiserad
Dispatcher cachning på AEM författare är begränsad till statiskt, icke-redigerat material. Detta gör det svårt och opraktiskt att cachelagra de flesta resurser på AEM Author, inklusive HTTP-svarshuvuden.
Nej
AEM Publish
Autentiserad
Undvik cachelagring av CORS-huvuden vid autentiserade begäranden. Detta anpassas till den vanliga vägledningen om att inte cachelagra autentiserade begäranden, eftersom det är svårt att avgöra hur autentiserings-/auktoriseringsstatusen för den begärande användaren kommer att påverka den levererade resursen.
Ja
AEM Publish
Anonym
Anonyma förfrågningar som kan cache-lagras hos dispatchern kan även ha sina svarshuvuden cachelagrade, vilket garanterar att framtida CORS-förfrågningar kan komma åt det cachelagrade innehållet. Alla ändringar av CORS-konfigurationen på AEM Publish måste följas av en ogiltigförklaring av de cachelagrade resurserna som påverkas. De bästa sätten är att styra koddistributioner och konfigurationsdistributioner eftersom det är svårt att avgöra vilket cachelagrat innehåll som kan utföras.

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 i com.adobe.granite.cors
  • 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.
  • vid behov, kontrollera om det finns autentiseringsuppgifter för begäran.

Stödmaterial

recommendation-more-help
c92bdb17-1e49-4e76-bcdd-89e4f85f45e6