Partage des ressources cross-origin Adobe Experience Manager (CORS) facilite les propriétés web non AEM pour effectuer des appels côté client vers AEM, authentifiés et non authentifiés, pour récupérer du contenu ou interagir directement avec l’.
Les configurations CORS sont gérées comme des usines de configuration OSGi dans AEM, chaque stratégie étant représentée comme une instance de la fabrique.
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
)
Une stratégie est sélectionnée en comparant la variable
Allowed Origin
avec le Origin
en-tête de requêteAllowed Paths
avec le chemin d’accès de la requête.La première stratégie correspondant à ces valeurs est utilisée. Si aucun n’est trouvé, n’importe lequel CORS la demande est refusée.
Si aucune stratégie n’est configurée, CORS les demandes ne seront pas non plus traitées puisque le gestionnaire est désactivé et donc refusé de manière efficace, à condition qu’aucun autre module du serveur ne réponde à CORS.
"alloworigin" <origin> | *
origin
paramètres spécifiant les URI pouvant accéder à la ressource. Pour les demandes sans informations d’identification, le serveur peut spécifier * comme caractère générique, permettant ainsi à toute origine d’accéder à la ressource. Il n’est absolument pas recommandé d’utiliser Allow-Origin: *
en production puisqu’il permet à chaque site web étranger (c’est-à-dire à un attaquant) de faire des demandes qui, sans CORS, sont strictement interdites par les navigateurs."alloworiginregexp" <regexp>
regexp
expressions régulières spécifiant des URI pouvant accéder à la ressource. Les expressions régulières peuvent générer des correspondances inattendues si elles ne sont pas soigneusement créées, ce qui permet à un attaquant d’utiliser un nom de domaine personnalisé qui correspondrait également à la stratégie. Il est généralement recommandé de disposer de stratégies distinctes pour chaque nom d’hôte d’origine spécifique, en utilisant alloworigin
, même si cela signifie une configuration répétée des autres propriétés de stratégie. Les origines différentes ont tendance à avoir des cycles de vie et des exigences différents, ce qui profite d'une séparation claire."allowedpaths" <regexp>
regexp
expressions régulières spécifiant les chemins d’accès aux ressources pour lesquels la stratégie s’applique."exposedheaders" <header>
"maxage" <seconds>
seconds
indiquant la durée pendant laquelle les résultats d’une demande de pré-vol peuvent être mis en cache."supportedheaders" <header>
header
paramètres indiquant quels en-têtes HTTP peuvent être utilisés lors de la requête réelle."supportedmethods"
"supportscredentials" <boolean>
boolean
indiquant si la réponse à la requête peut être exposée au navigateur. Utilisé dans le cadre d’une réponse à une demande de pré-vol, cela indique si la demande réelle peut être effectuée à l’aide des informations d’identification.Le site 1 est un scénario de base, accessible anonymement et en lecture seule où le contenu est utilisé par GET requests :
{
"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",
]
}
Le site 2 est plus complexe et nécessite des requêtes autorisées et de mutation (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"
]
}
À partir de la version 4.1.1+ de Dispatcher, les en-têtes de réponse peuvent être mis en cache. Cela permet de mettre en cache CORS en-têtes le long de la propriété CORS- ressources demandées, tant que la demande est anonyme.
En règle générale, les mêmes considérations relatives à la mise en cache de contenu dans Dispatcher peuvent être appliquées à la mise en cache des en-têtes de réponse CORS au Dispatcher. Le tableau suivant définit quand CORS en-têtes (et donc CORS requêtes) peuvent être mises en cache.
Mise en cache | Environnement | État d’authentification | Explication |
---|---|---|---|
Non | Publication AEM | Authentifié | La mise en cache de Dispatcher sur l’auteur AEM est limitée aux ressources statiques non créées. Il est ainsi difficile et impossible de mettre en cache la plupart des ressources sur AEM Author, y compris les en-têtes de réponse HTTP. |
Non | Publication AEM | Authentifié | Évitez de mettre en cache les en-têtes CORS sur les requêtes authentifiées. Cela s’aligne sur les conseils courants de ne pas mettre en cache les requêtes authentifiées, car il est difficile de déterminer comment l’état d’authentification/d’autorisation de l’utilisateur demandeur affectera la ressource diffusée. |
Oui | Publication AEM | Anonyme | Les en-têtes de réponse des requêtes anonymes pouvant être mises en cache dans Dispatcher peuvent également être mis en cache, ce qui garantit que les futures requêtes CORS pourront accéder au contenu mis en cache. Toute modification de configuration CORS sur AEM Publish must être suivie d’une invalidation des ressources mises en cache affectées. Les bonnes pratiques dictent les déploiements de code ou de configuration que le cache du Dispatcher est purgé, car il est difficile de déterminer quel contenu mis en cache peut être affecté. |
Pour permettre la mise en cache des en-têtes CORS, ajoutez la configuration suivante à tous les fichiers dispatcher.any de publication AEM pris en charge.
/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"
}
...
}
N’oubliez pas de redémarrez l’application du serveur web. après avoir apporté des modifications à la variable dispatcher.any
fichier .
Il est probable que l’effacement complet du cache soit nécessaire pour s’assurer que les en-têtes sont correctement mis en cache dans la requête suivante après une /cache/headers
mise à jour de la configuration.
La journalisation est disponible sous com.adobe.granite.cors
:
DEBUG
pour afficher des détails sur les raisons pour lesquelles une CORS demande refuséeTRACE
pour afficher les détails sur toutes les requêtes qui passent par le gestionnaire CORSAccess-Control-Allow-Origin
L’en-tête est absent de la réponse ; passez en revue les journaux pour les refus sous DEBUG in com.adobe.granite.cors
/cache/headers
La configuration s’applique à dispatcher.any
et le redémarrage du serveur web