AEM-Zuordnungen für die Verwaltung von mehreren Domänen zur Verkürzung der URL | AEM 6.x

Zielsetzung

Es ist durchaus üblich, dass eine einzige AEM-Instanz mehrere Websites verwaltet. Normalerweise wird jeder Seite eine eigene Domäne zugewiesen und es können einige Sprachversionen vorhanden sein. Für eine solche Installation mit mehreren Domänen ist eine zusätzliche, nicht triviale Konfiguration erforderlich. Dieser Beitrag soll als Kurzreferenzdokument dienen, in dem Sie erfahren können, wie Sie 3 Sprachversionen der bekannten Geometrixx-Site für 3 Domänen konfigurieren: geometrixx.com, geometrixx.de und geometrixx.fr.

Schritte


		
	





Lassen Sie uns zunächst AEM selbst konfigurieren (mit der Sling-Zuordnungs-Engine). Erstellen Sie Apache-Umschreibungsregeln und VirtualHosts, beseitigen Sie die Bedrohung durch domänenübergreifende Cache-Injizierung, und schließlich führen wir die Überarbeitung der Apache-Konfiguration durch, um sie übersichtlicher zu machen.

Sling-Zuordnungs-Engine

Der beste Weg, um einen Domainnamen einer Website in AEM zuzuordnen, ist die Verwendung von Sling-Zuordnungen. Zuordnungen bieten zwei nützliche Funktionen:

  • Lange Links im Seiteninhalt werden auf ein benutzerfreundliches Format gekürzt,
  • kurze Links werden zu einem vollständigen Inhaltspfad aufgelöst.

Um die eingehenden URLs wieder im langen Format von of /content/sitename zu schreiben, nutzen wir mod_rewrite auf Apache-Ebene. Sie können Verknüpfungen im ausgehenden HTML-Code jedoch nicht ohne Module wie mod_subsitute verkürzen. Um die HTML-Ausgabe (z. B. <a href=...> Attribute) neu zu schreiben, verwenden wir Sling-Zuordnungen unter /etc/map.publish, um die URLs zuzuordnen.  AEMs vorkonfigurierter Link-Neuschreiber verwendet dann ResourceResolver.map, um diese Zuordnungen in den HTML-Code zu schreiben.  Standardmäßig werden Zuordnungen in der JCR unter dem Knoten /etc/map/http platziert.  Der Knoten /etc/map/http wirkt sich nicht nur auf Veröffentlichungsinstanzen, sondern auch auf Autoreninstanzen aus.  Stattdessen verwenden wir /etc/map.publish, sodass nur Veröffentlichungsinstanzen betroffen sind.  Auf diese Weise können Sie ein gemeinsames Paket mit Zuordnungen für Autoren- und Veröffentlichungsinstanzen verwenden.

Hinweis:

Damit der abweichende Speicherort /etc/map von /etc/map.publish auf der Veröffentlichungsinstanz geladen werden kann, müssen wir eine OSGi-Konfiguration aktualisieren.  Ändern Sie die Eigenschaft resource.resolver.map.location in der Konfiguration von der OSGi-Konfiguration org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl in /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: "(.+)$" 
    } 
  }, 
  ... 
}

Nach drei Punkten in Zeile 16 gibt es ähnliche Einträge für .de- und .fr-Domänen: geometrixx_de mit geometrixx.de und geometrixx_fr mit geometrixx.fr.

Die Zuordnung geometrixx_com (Zeilen 3 - 7) ist für die Umleitung auf die Stammseite verantwortlich. Wenn der Benutzer geometrixx.com eingibt, erhält er die Seite /content/geometrixx/de.html. Das Dollarzeichen am Ende von sling:match (6) ist ein „Regexp“-Steuerzeichen, welches das „Ende der Zeichenfolge“ bedeutet. Dies führt dazu, dass diese Zuordnung nicht anwendbar ist, wenn der Benutzer nach dem Schrägstrich einen Pfad eingibt.

Die Zuordnung von geometrixx.com (8 - 16) ist komplexer. Es besteht aus dem übergeordneten Element (8 - 16) und untergeordneten Element (11 - 5). Das übergeordnete Element enthält nicht die Eigenschaft sling:match. Der Knotenname (geometrixx.com) wird daher als URL-Muster verwendet. Dieser Eintrag ist dafür verantwortlich, lange Links in ein kürzeres Format mit einem Domänennamen zu verkürzen, z. B. /content/geometrixx/en/products will be shortened to geometrixx.com/products.html.

Ein untergeordneter Eintrag ist für die URL-Auflösung verantwortlich. Um diese Zuordnung abgleichen zu können, muss eine URL mit geometrixx.com (einer Domäne, die von der übergeordneten Zuordnung übernommen wurde) beginnen und anschließend eine nicht leere Pfadzeichenfolge (regulärer Ausdruck (+)$ in Zeile 14)enthalten. sling:internalRedirect in Zeile 12 enthält eine Liste mit zwei Einträgen: /$1 und /content/geometrixx/en/$1. Wenn der Benutzer geometrixx.com/etc/designs/geometrixx.css eingibt, wird der erste Eintrag verwendet. Wenn der Benutzer geometrixx.com/products.html eingibt, wählt Sling die Zweite aus und gibt /content/geometrixx/de/products.html zurück.

Sie können die Zuordnungen mit der Apache Felix-Webkonsole ausprobieren. Klicken Sie einfach im Menü auf den Link „Sling Resource Resolver“.

Apache mod_rewrite

Nachdem Sie Zuordnungen definiert haben (und wahrscheinlich eine geeignete Domäne zur Hosts-Datei hinzugefügt haben), können wir unsere AEM-Installation mit mehreren Domänen mit kurzen Links genießen. Es gibt nur ein Problem: Ein Dispatcher. Wenn wir eine standardmäßige Dispatcher-Konfiguration verwenden, gibt es für alle Websites ein Cache-Verzeichnis. Wenn der Benutzer die Seite geometrixx.com/products.html anfordert, erstellt ein Dispatcher die Datei /products.html im Cache-Verzeichnis. Wenn nun ein anderer Benutzer die Seite geometrixx.de/products.html anfordert, findet ein Dispatcher die zwischengespeicherte englische Version und stellt sie dem deutschen Benutzer zur Verfügung. Um solche Probleme zu vermeiden, sollten wir die JCR-Verzeichnisstruktur in einem Dispatcher widerspiegeln. Der einfachste Weg, um kürzere Pfade zu erweitern, ist die Verwendung der Apache-Umschreibungs-Engine. Grundsätzlich versuchen wir, den Sling-Auflösungsmechanismus zu simulieren. Die folgenden Regeln führen den Auftrag aus:

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]

Zu Beginn (1) prüfen wir, ob die eingegebene URL einen leeren Pfad enthält (z. B. http://geometrixx.com/). Ist dies der Fall, wird der Benutzer auf die Startseite weitergeleitet. Andernfalls prüfen wir, ob der eingegebene Pfad verkürzt ist (er beginnt nicht mit Apps, Inhalt, Startseite usw. - Linien 2 - 8). Ist dies der Fall, fügt die Umschreibungs-Engine /content/geometrixx/en hinzu, während der absolute Pfad (9) erstellt wird.

Apache VirtualHost

Wie Sie sehen, gilt diese Regel nur für die Domäne geometrixx.com. Daher benötigen wir für jede Domäne ähnliche Regeln und irgendeinen Mechanismus zum Erkennen einer aktuellen Domäne. Ein solcher Mechanismus in Apache wird als VirtualHost bezeichnet. Eine Beispielkonfigurationsdatei für Apache2 VirtualHost sieht folgendermaßen aus:

<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>

Alle VirtualHosts können ein freigegebenes Dispatcher-Verzeichnis verwenden. Erstellen Sie für jede Domäne ähnliche Dateien.

Domänenübergreifende Injektionsbedrohung

Da Benutzer nach einem bestimmten Domänennamen einen vollständigen Inhaltspfad eingeben können, z. B. geometrixx.com/content/geometrixx/en/products.html, erhalten sie möglicherweise eine Seite, die zu einer anderen Domäne gehört, z. B. geometrixx.com/content/geometrixx/fr/products.html. Um eine solche Situation zu vermeiden, müssen wir alle Anforderungen für den Pfad, der mit /content beginnt, prüfen und die, die sich nicht auf eine Kampagne, ein DAM oder eine aktuelle Domäne beziehen, ablehnen:

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

Makros

Unsere Umschreibungskonfiguration ist ziemlich kompliziert und (was noch schlimmer ist) sie muss in jeder Apache VirtualHost-Konfiguration enthalten sein. Glücklicherweise können wir Wiederholungen mit dem Apache-Makromodul vermeiden. Fügen Sie Ihrem Verzeichnis „conf.d“ die folgende Datei „expand-aem-paths“ hinzu:

<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>

Danach können Sie mit der Direktive „Verwenden“ ein Makro in jeden VirtualHost einfügen:

Use ExpandAEMPaths /content/geometrixx/en

Da es sich beim Makromodul um eine externe Apache2-Bibliothek handelt, müssen Sie es möglicherweise separat installieren. Unter Debian können Sie es mit zwei Befehlen installieren und aktivieren:

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

Wenn Sie eine andere Linux-Distribution oder Windows verwenden, finden Sie die entsprechende Version des Moduls und die Installationsanweisung auf der mod_macro-Startseite.

Dispatcher-Konfiguration

Sie können die vorkonfigurierte Dispatcher-Konfiguration verwenden. Die einzige Annahme ist, dass die Docroot auf /opt/aem/dispatcher/publish festgelegt ist.

Übersicht

Sie haben jetzt eine AEM-Installation mit 3 Domänen konfiguriert, wobei Sling-Zuordnungen, Apache 2-mod_rewrite und VirtualHost-Mechanismen verwendet werden. Wir haben auch domänenübergreifende Injektionsangriffe verhindert und mit mod_macro eine Überarbeitung der Apache 2-Konfiguration durchgeführt. Die oben beschriebene Konfiguration sollte ausreichen, um eine benutzerdefinierte Installation mit mehreren Domänen von Grund auf vorzubereiten.

 Adobe

Schneller und einfacher Hilfe erhalten

Neuer Benutzer?