Mappages AEM de gestion multi-domaines pour le raccourcissement des URL | AEM 6.x

Rechercher

Dernière mise à jour le 2 mai 2021

Objectif

Il est très fréquent qu’une seule instance AEM gère plusieurs sites. En règle générale, chaque page dispose d’un domaine distinct et peut avoir quelques versions linguistiques. Une telle configuration multi-domaine nécessite une configuration supplémentaire et non triviale. Cette publication est destinée à servir de document référence rapide vous permettant de savoir comment configurer 3 versions linguistiques du sitebien connu Geometrixx sur 3 domaines : geometrixx.com, geometrixx.de et geometrixx.fr.

Étapes

Commencez par configurer AEM lui-même (avec le moteur de mappages Sling), créer des règles de réécriture Apache et VirtualHosts, éliminer la menace d’injection de cache entre domaines et enfin refactoriser la configuration d’Apache pour la rendre plus concise.

Moteur de mappages Sling

Le meilleur moyen de mapper un nom de domaine sur un site Web dans AEM consiste à utiliser les mappages Sling. Les mappages proposent deux fonctions utiles :

Les liens longs du contenu de la page sont raccourcis sous un format pratique,
Les liens courts sont résolus vers un chemin de contenu complet.

Pour réécrire les URL entrantes dans le format long /content/QC, nous exploitons mod_rewrite au niveau Apache. Cependant, vous ne pouvez pas raccourcir les liens dans le code HTML sortant sans modules tels que mod_subsitute. Ainsi, pour réécrire la sortie HTML (par exemple, les attributs <a href=...>) nous utilisons les mappages Sling sous /etc/map.publish pour mapper les URL. Ensuite, la réécriture du lien d’usine AEM utilise ResourceResolver.map pour réécrire ces mappages dans le code HTML. Par défaut, les mappages sont placés dans le JCR sous le nœud /etc/map/http. Le nœud /etc/map/http affecte les instances d’auteur en plus de publier des instances. Ainsi, nous utiliserons /etc/map.publish afin que seules les instances de publication soient concernées. Ainsi, vous pouvez utiliser un package commun avec des mappages pour les instances d’auteur et de publication.

Remarque :

Pour les différents /etc/map de /etc/map.publish à charger sur les instances de publication, nous devons mettre à jour une configuration OSGi. Remplacez la propriété resource.resolver.map.location dans la configuration OSGi org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl avec /etc/map.publish.

{ 
  jcr: primaryType: "sling:OrderedFolder", 
  geometrixx_com: { 
    sling:internalRedirect: ["/content/geometrixx/en.html"], 
    jcr:primaryType: "sling:Mapping", 
    sling:match: "geometrixx.com/$" 
  }, 
  geometrixx.com: { 
    sling:internalRedirect: ["/content/geometrixx/en"], 
    jcr:primaryType: "sling:Mapping", 
    redirect: { 
      sling:internalRedirect: ["/$1","/content/geometrixx/en/$1"], 
      jcr:primaryType: "sling:Mapping", 
      sling:match: "(.+)$" 
    } 
  }, 
  ... 
}

Les trois points de la ligne 16 contiennent des entrées similaires pour .de et .fr domaines : geometrixx_de avec geometrixx.de et geometrixx_fr avec geometrixx.fr.

Le mappage des geometrixx_com (lignes 3-7) est chargé de la redirection vers la page racine. Ainsi, si l’utilisateur accède à geometrixx.com, il ou elle reçoit la page /content/geometrixx/en.html. Le signe dollar à la fin de sling:match (6) est un caractère de contrôle regexp « fin de chaîne », ce qui implique que ce mappage ne sera pas applicable si l’utilisateur accède à n’importe quel chemin après la barre oblique.

Le mappage de geometrixx.com (8-16) est plus complexe. Elle se compose du parent (8-16) et de l’enfant (11-5). Le parent ne contient pas la propriété sling:match. Par conséquent, le nom du nœud (geometrixx.com) est utilisé comme modèle d’URL. Cette entrée est chargée de réduire les liens longs en un format plus court avec un nom de domaine, par exemple /content/geometrixx/en/products will be shortened to geometrixx.com/products.html.

Une entrée enfant est responsable de la résolution des URL. Pour correspondre à ce mappage, une URL doit commencer par geometrixx.com (un domaine hérité du mappage parent) et après cela, il doit contenir une chaîne de chemin non vide (expression régulière (.+)$ à la ligne 14). sling:internalRedirect à la ligne 12 est une liste contenant deux entrées : /$1 et /content/geometrixx/en/$1. Si l’utilisateur accède à geometrixx.com/etc/designs/geometrixx.css, la première entrée sera utilisée. Si l’utilisateur accède à geometrixx.com/products.html, Sling choisit le deuxième et renvoie /content/geometrixx/en/products.html.

Vous pouvez lire avec des mappages en utilisant la console web Apache Felix. Il vous suffit de cliquer sur le lien Sling Resource Resolver dans le menu.

Apache mod_rewrite

Après avoir défini des mappages (et probablement en ajoutant un domaine approprié au fichier hosts), nous pouvons profiter de notre installation multi-domaine AEM avec des liens courts. Il n’existe qu’un seul problème : un répartiteur. Si nous utilisons une configuration de répartiteur standard, il y a un répertoire de mémoire cache pour tous les sites. Si l’utilisateur demande la page geometrixx.com/products.html, un répartiteur crée le fichier /products.html dans le nettoyeur de mémoire cache. Maintenant, si un autre utilisateur demande la page geometrixx.de/products.html, un répartiteur trouvera sa version anglaise en cache et le fera pointer vers l’utilisateur allemand. Afin d’éviter ce type de problème, nous devrions refléter la structure de répertoire JCR dans un répartiteur. La façon la plus simple d’étendre les chemins raccourcis est d’utiliser Apache rewrite engine. Essentiellement, nous allons tenter de simuler le mécanisme de résolution de Sling. Les règles suivantes permettent d’effectuer cette opération :

RewriteEngine On 
RewriteRule ^/$ /content/geometrixx/en.html [PT,L] 
RewriteCond %{REQUEST_URI} !^/apps 
RewriteCond %{REQUEST_URI} !^/bin 
RewriteCond %{REQUEST_URI} !^/content 
RewriteCond %{REQUEST_URI} !^/etc 
RewriteCond %{REQUEST_URI} !^/home 
RewriteCond %{REQUEST_URI} !^/libs 
RewriteCond %{REQUEST_URI} !^/tmp 
RewriteCond %{REQUEST_URI} !^/var 
RewriteCond %{REQUEST_URI} !^/dispatcher 
RewriteRule ^/(.*)$ /content/geometrixx/en/$1 [PT,L]

Au début (1), nous vérifions si l’URL entrée contient un chemin vide (par ex. http://geometrixx.com/). Si c’est le cas, l’utilisateur sera redirigé vers la page d’accueil. Dans le cas contraire, nous vérifions si le chemin saisi est raccourci (ne commence pas par apps, content, home, etc. - lignes 2 à 8). Si c’est le cas, le moteur de réécriture ajoutera /content/geometrixx/en lors de la création du chemin absolu (9).

Apache VirtualHost

Comme vous pouvez le constater, cette règle n’est valide que pour le domaine geometrixx.com. Par conséquent, nous avons besoin de règles similaires pour chaque domaine et d’un mécanisme pour reconnaître un domaine qui en est un. Un tel mécanisme dans Apache est appelé VirtualHost. Voici un exemple de fichier de configuration Apache2 VirtualHost :

<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName geometrixx.com

DocumentRoot /opt/aem/dispatcher/publish
<Directory /opt/aem/dispatcher/publish>
Options FollowSymLinks
AllowOverride None
</Directory>

<IfModule disp_apache2.c>
SetHandler dispatcher-handler
</IfModule>

[... above rewrite rules ...]

LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access-geo-en.log combined
ErrorLog ${APACHE_LOG_DIR}/error-geo-en.log
</VirtualHost>

Tous les VirtualHosts peuvent utiliser un répertoire de répartiteur partagé. Créez des fichiers similaires pour chaque domaine.

Risque d’injection inter-domaine

Comme les utilisateurs peuvent entrer un chemin d’accès au contenu complet après un nom de domaine donné, par exemple geometrixx.com/content/geometrixx/en/products.html, ils peuvent également se voir attribuer une page appartenant à un autre domaine, par exemple geometrixx.com/content/geometrixx/fr/products.html. Pour éviter ce type de situation, nous devons vérifier toutes les requêtes de chemin commençant par /content et rejeter celles qui ne sont liées à aucune campagne, aucune gestion des actifs numériques (DAM) ou à aucun domaine actuel :

RewriteCond %{REQUEST_URI} ^/content
RewriteCond %{REQUEST_URI} !^/content/campaigns
RewriteCond %{REQUEST_URI} !^/content/dam
RewriteRule !^/content/geometrixx/en - [R=404,L,NC]

Macros

Notre configuration de réécriture est devenue plus complexe et pire encore, elle doit être incluse dans chaque configuration Apache VirtualHost. Heureusement, nous pouvons éviter les repetitions à l’aide du module de macro Apache. Ajoutez le fichier expand-aem-paths ci-dessous dans votre répertoire conf.d :

<Macro ExpandAEMPaths $path>
RewriteEngine On

RewriteRule ^/$ $path.html [PT,L]

RewriteCond %{REQUEST_URI} ^/content
RewriteCond %{REQUEST_URI} !^/content/campaigns
RewriteCond %{REQUEST_URI} !^/content/dam
RewriteRule !^$path - [R=404,L,NC]

RewriteCond %{REQUEST_URI} !^/apps
RewriteCond %{REQUEST_URI} !^/content
RewriteCond %{REQUEST_URI} !^/etc
RewriteCond %{REQUEST_URI} !^/home
RewriteCond %{REQUEST_URI} !^/libs
RewriteCond %{REQUEST_URI} !^/tmp
RewriteCond %{REQUEST_URI} !^/var
RewriteRule ^/(.*)$ $path/$1 [PT,L]
</Macro>

Après cela, vous pouvez inclure une macro dans chaque VirtualHost avec la directive Use :

Use ExpandAEMPaths /content/geometrixx/en

Le module Macro étant une bibliothèque externe Apache2, vous devrez peut-être l’installer séparément. Sur Debian, vous pouvez l’installer et l’activer à l’aide de deux commandes :

# apt-get install libapache2-mod-macro
# a2enmod macro

Si vous utilisez une autre distribution Linux ou Windows, veuillez trouver la version appropriée du module et les instructions d’installation sur la page d’accueil mod_macro.

Configuration du Dispatcher

Vous pouvez utiliser la configuration standard du répartiteur. La seule condition est que sa propriété docroot soit défini sur /opt/aem/dispatcher/publish.

Résumé

Désormais, vous avez configuré une installation AEM avec 3 domaines, à l’aide des mappages Sling, Apache 2 mod_rewrite et VirtualHost. Nous avons également empêché les attaques par injection inter-domain et effectué une configuration d’usine d’Apache 2 en utilisant mod_macro. La configuration décrite ci-dessus doit être suffisante pour préparer une installation multi-domain personnalisée de A à Z.