Förstå resursdelning mellan ursprung (CORS)

Adobe Experience Manager Cross-Origin Resource Sharing (CORS) underlättar för icke-AEM webbegenskaper att ringa 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 med ett ursprung vid AEM publicering
  2. CORS åtkomst till AEM Author

Om CORS-åtkomst med flera ursprung krävs vid AEM publicering, 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 Origin begärandehuvud
  • och Allowed Paths med sökvägen till begäran.

Den första principen som matchar dessa värden används. Om inga hittas, CORS begäran nekas.

Om ingen princip är konfigurerad alls CORS förfrågningar besvaras inte heller 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 över origin parametrar som anger URI som kan komma åt resursen. För begäranden utan autentiseringsuppgifter kan servern ange * som jokertecken, vilket ger alla ursprung åtkomst till resursen. Vi rekommenderar absolut inte att du använder Allow-Origin: * i produktion eftersom alla externa (dvs. angripare) webbplatser kan göra förfrågningar som inte har CORS är strängt förbjudna av webbläsare.

Allowed Origins (Regexp)

  • "alloworiginregexp" <regexp>
  • Lista över regexp reguljära uttryck som anger URI 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 profilen. Vi rekommenderar att du har olika 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 över 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 Access-Control-Expose-Headers svarshuvud. 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>
  • A seconds parameter som anger hur länge resultatet av en preflight-förfrågan kan cachas.

Supported Headers

  • "supportedheaders" <header>
  • Lista över header parametrar som anger vilka rubriker i 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>
  • A boolean ange 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

Webbplats 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 cacheminnesproblem 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 sidhuvuden längs med CORS-begärda resurser, förutsatt att begäran är anonym.

I allmänhet kan samma överväganden för att cachelagra innehåll vid Dispatcher användas för att cachelagra CORS-svarshuvuden vid dispatcher. Följande tabell definierar när CORS rubriker (och därmed CORS begäranden) kan cachas.

Cacheable
Miljö
Autentiseringsstatus
Förklaring
Nej
AEM Publish
Autentiserad
Cachelagring av AEM författare är begränsad till statiskt, icke-författarbaserat 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 i CORS-konfigurationen vid AEM måste följas av en ogiltigförklaring av de cachelagrade resurser 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

För att tillåta HTTP-begäranrubriker som skickas till AEM för bearbetning, måste de vara tillåtna i Disaptcher's /clientheaders konfiguration.

/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 till AEM Publish dispatcher.any -fil.

/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 starta om webbserverprogrammet efter att ha ändrat dispatcher.any -fil.

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 finns under com.adobe.granite.cors:

  • enable DEBUG om du vill veta mer om varför CORS begäran nekades
  • enable TRACE för att se information om alla förfrågningar 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 ingen rubrik finns på svaret. Granska loggarna för nekanden under DEBUG in com.adobe.granite.cors
  • Om dispatcher cachelagrar CORS begäran är aktiverad

    • Kontrollera /cache/headers konfiguration tillämpas på dispatcher.any och 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