Comprendere la condivisione delle risorse tra le origini (CORS)
La condivisione delle risorse tra le origini di Adobe Experience Manager (CORS) facilita le proprietà Web non AEM per effettuare chiamate lato client all'AEM, autenticate e non autenticate, per recuperare contenuto o interagire direttamente con l'AEM.
La configurazione OSGI descritta in questo documento è sufficiente per:
- Condivisione di risorse a origine singola su AEM Publish
- Accesso CORS all’istanza di creazione dell’AEM
Se è necessario l'accesso CORS a più origini nel Publish AEM, consulta questa documentazione.
Adobe di configurazione OSGi dei criteri di condivisione delle risorse tra origini diverse di Granite
Le configurazioni CORS sono gestite come factory di configurazione OSGi in AEM, dove ogni criterio è rappresentato come un'istanza della factory.
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
)
Selezione criteri
Per selezionare un criterio, confronta il
Allowed Origin
con intestazione di richiestaOrigin
- e
Allowed Paths
con il percorso della richiesta.
Vengono utilizzati i primi criteri che corrispondono a questi valori. Se non viene trovata alcuna richiesta, qualsiasi richiesta CORS verrà negata.
Se non è configurato alcun criterio, non verrà fornita risposta neanche alle richieste CORS perché il gestore è disabilitato e quindi negato in modo effettivo, purché nessun altro modulo del server risponda a CORS.
Proprietà dei criteri
Origini consentite
"alloworigin" <origin> | *
- Elenco di
origin
parametri che specificano gli URI che possono accedere alla risorsa. Per le richieste senza credenziali, il server può specificare * come carattere jolly, consentendo in tal modo a qualsiasi origine di accedere alla risorsa. Non è assolutamente consigliabile utilizzareAllow-Origin: *
in produzione in quanto consente a ogni sito Web esterno (ad esempio, un utente non autorizzato) di effettuare richieste che senza CORS sono severamente vietate dai browser.
Origini consentite (Regexp)
"alloworiginregexp" <regexp>
- Elenco di
regexp
espressioni regolari che specificano gli URI che possono accedere alla risorsa. Le espressioni regolari possono causare corrispondenze non desiderate se non vengono create con attenzione, consentendo a un utente non autorizzato di utilizzare un nome di dominio personalizzato che corrisponda anche al criterio. In genere si consiglia di disporre di criteri separati per ogni nome host di origine specifico, utilizzandoalloworigin
, anche se ciò significa la configurazione ripetuta delle altre proprietà dei criteri. Origini diverse tendono ad avere cicli di vita e requisiti diversi, beneficiando così di una netta separazione.
Percorsi consentiti
"allowedpaths" <regexp>
- Elenco di
regexp
espressioni regolari che specificano i percorsi delle risorse a cui si applica il criterio.
Intestazioni esposte
"exposedheaders" <header>
- Elenco di parametri di intestazione che indicano le intestazioni di risposta a cui i browser possono accedere. Per le richieste CORS (non pre-flight), se non vuote, questi valori vengono copiati nell'intestazione di risposta
Access-Control-Expose-Headers
. I valori nell’elenco (nomi delle intestazioni) vengono quindi resi accessibili al browser; senza di esso, tali intestazioni non sono leggibili dal browser.
Età massima
"maxage" <seconds>
- Un parametro
seconds
che indica per quanto tempo è possibile memorizzare nella cache i risultati di una richiesta di pre-volo.
Intestazioni supportate
"supportedheaders" <header>
- Elenco di
header
parametri che indicano quali intestazioni di richiesta HTTP possono essere utilizzate quando si effettua la richiesta effettiva.
Metodi consentiti
"supportedmethods"
- Elenco dei parametri di metodo che indicano quali metodi HTTP possono essere utilizzati quando si effettua la richiesta effettiva.
Supporta Le Credenziali
"supportscredentials" <boolean>
- Un
boolean
che indica se la risposta alla richiesta può essere esposta o meno al browser. Se utilizzata come parte di una risposta a una richiesta di pre-volo, indica se la richiesta effettiva può essere effettuata o meno utilizzando le credenziali.
Esempi di configurazioni
Il sito 1 è uno scenario di base, anonimamente accessibile e di sola lettura in cui il contenuto viene utilizzato tramite GET richieste:
{
"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"
]
}
Il sito 2 è più complesso e richiede richieste autorizzate e mutanti (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"
]
}
Problemi e configurazione relativi alla memorizzazione nella cache di Dispatcher dispatcher-caching-concerns-and-configuration
A partire da Dispatcher 4.1.1+, le intestazioni di risposta possono essere memorizzate nella cache. In questo modo è possibile memorizzare nella cache CORS intestazioni insieme alle risorse richieste da CORS, purché la richiesta sia anonima.
In generale, le stesse considerazioni per la memorizzazione in cache del contenuto in Dispatcher possono essere applicate alla memorizzazione in cache delle intestazioni di risposta CORS in Dispatcher. La tabella seguente definisce quando è possibile memorizzare in cache CORS intestazioni (e quindi CORS richieste).
Consentire le intestazioni di richiesta CORS
Per consentire alle intestazioni di richiesta HTTP di passare all'AEM per l'elaborazione, è necessario che siano consentite nella configurazione di Dispatcher /clientheaders
.
/clientheaders {
...
"Origin"
"Access-Control-Request-Method"
"Access-Control-Request-Headers"
}
Memorizzazione nella cache delle intestazioni di risposta CORS
Per consentire il caching e il serving delle intestazioni CORS sul contenuto memorizzato nella cache, aggiungere la seguente configurazione /cache /headers al file AEM Publish dispatcher.any
.
/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"
}
...
}
...
}
Ricordarsi di riavviare l'applicazione server Web dopo aver apportato modifiche al file dispatcher.any
.
È probabile che la cancellazione completa della cache sia necessaria per garantire che le intestazioni siano memorizzate nella cache in modo appropriato alla successiva richiesta dopo un aggiornamento della configurazione di /cache/headers
.
Risoluzione dei problemi CORS
Registrazione disponibile in com.adobe.granite.cors
:
- abilita
DEBUG
per visualizzare i dettagli sul motivo per cui una richiesta CORS è stata negata - abilita
TRACE
per visualizzare i dettagli di tutte le richieste effettuate tramite il gestore CORS
Suggerimenti:
-
Ricreare manualmente le richieste XHR utilizzando CURL, ma assicurati di copiare tutte le intestazioni e i dettagli, in quanto ciascuno può fare la differenza; alcune console del browser consentono di copiare il comando CURL
-
Verifica se la richiesta è stata negata dal gestore CORS e non dall’autenticazione, dal filtro token CSRF, dai filtri del dispatcher o da altri livelli di sicurezza
- Se il gestore CORS risponde con 200, ma l'intestazione
Access-Control-Allow-Origin
è assente nella risposta, esaminare i registri per le negazioni in DEBUG incom.adobe.granite.cors
- Se il gestore CORS risponde con 200, ma l'intestazione
-
Se la memorizzazione nella cache del dispatcher di CORS richieste è abilitata
- Verificare che la configurazione
/cache/headers
sia applicata adispatcher.any
e che il server Web sia stato riavviato correttamente - Assicurati che la cache sia stata cancellata correttamente dopo qualsiasi modifica alla configurazione OSGi o dispatcher.any.
- Verificare che la configurazione
-
se necessario, controlla la presenza delle credenziali di autenticazione nella richiesta.