AEM-Entwicklung – Richtlinien und Best Practices

Richtlinien für die Verwendung von Vorlagen und Komponenten

Adobe Experience Manager (AEM)-Komponenten und -Vorlagen verfügen über ein leistungsstarkes Toolkit. Sie können von Entwicklern verwendet werden, um Benutzern, Editoren und Administratoren von Websites die Möglichkeit zu geben, ihre Websites an die sich ändernden Geschäftsanforderungen anzupassen (Inhaltserstellung). All dies unter Beibehaltung des einheitlichen Layouts der Websites (Markenschutz).

Eine typische Herausforderung für eine Person, die für eine Website oder eine Reihe von Websites verantwortlich ist (z. B. in einer Zweigstelle eines globalen Unternehmens), besteht darin, eine neue Art der Präsentation von Inhalten auf ihren Websites einzuführen.

Angenommen, eine Newslisten-Seite, die Auszüge aus bereits veröffentlichten Artikeln enthält, muss zu den Websites hinzugefügt werden. Die Seite sollte dasselbe Design und dieselbe Struktur aufweisen wie der Rest der Website.

Die empfohlene Vorgehensweise bei einer solchen Herausforderung wäre:

• Verwenden Sie eine vorhandene Vorlage erneut, damit Sie einen neuen Seitentyp erstellen können. Die Vorlage definiert grob die Seitenstruktur (Navigationselemente, Bedienfelder usw.), die durch ihr Design (CSS, Grafiken) weiter optimiert wird.
• Verwenden Sie das Absatzsystem (parsys/iparsys) auf den neuen Seiten.
• Definieren Sie Zugriffsberechtigungen für den Design-Modus der Absatzsysteme, damit diese nur von berechtigten Personen (normalerweise der Administrator) geändert werden können.
• Definieren Sie die im angegebenen Absatzsystem zulässigen Komponenten, damit Editoren die erforderlichen Komponenten dann auf der Seite platzieren können. In diesem Fall kann es sich um eine Listenkomponente handeln, die eine Unterstruktur von Seiten durchlaufen und die Informationen anhand vordefinierter Regeln extrahieren kann.
• Bearbeiter fügen die zulässigen Komponenten zu den Seiten hinzu, für die sie verantwortlich sind, und konfigurieren sie, um die angeforderte Funktionalität (Informationen) für das Unternehmen bereitzustellen.

Das Beispiel zeigt, wie es dieser Ansatz den beitragsleistenden Benutzern und Administratoren der Website ermöglicht, schnell auf Geschäftsanforderungen zu reagieren, ohne das Entwicklungsteam einbeziehen zu müssen. Alternative Methoden wie das Erstellen einer Vorlage sind in der Regel eine kostspielige Übung, die einen Change-Management-Prozess und die Einbeziehung des Entwicklungsteams erfordert. Dadurch wird der gesamte Prozess länger und kostspielig.

Die Entwickler AEM Systeme sollten daher Folgendes verwenden:

• Vorlagen und Zugriffskontrolle für die Konstruktion von Absatzsystemen für Einheitlichkeit und Markenschutz
• Absatzsystem einschließlich der Konfigurationsoptionen für Flexibilität.

Die folgenden allgemeinen Regeln für Entwickler sind in den meisten gängigen Projekten sinnvoll:

• Halten Sie die Anzahl der Vorlagen gering - so gering wie die Anzahl grundlegend unterschiedlicher Seitenstrukturen auf den Websites.
• Stellen Sie die erforderlichen Flexibilität und Konfigurationsfunktionen für Ihre benutzerdefinierten Komponenten bereit.
• Maximieren Sie die Nutzung der Leistung und Flexibilität des AEM Absatzsystems - der parsys- und iparsys-Komponenten.

Anpassen von Komponenten und anderen Elementen

Wenn Sie eigene Komponenten erstellen oder eine vorhandene Komponente anpassen, ist es häufig am einfachsten (und sichersten), vorhandene Definitionen wiederzuverwenden. Dasselbe gilt auch für andere Elemente in AEM, z. B. für den Fehler-Handler.

Kopieren Sie dazu die vorhandene Definition und überlagern Sie sie, wie nachfolgend beschrieben: Mit anderen Worten, kopieren Sie die Definition von /libs zu /apps/<your-project>. Sie können die neue Definition in /apps Anforderungen entsprechend aktualisieren.

Beispiel:

• Anpassen einer Komponente

  Dazu gehörte das Überlagern einer Komponentendefinition:

  • Erstellen Sie einen Komponentenordner in /apps/<website-name>/components/<MyComponent> durch Kopieren einer vorhandenen Komponente:

    • Um beispielsweise die Textkomponente anzupassen, kopieren Sie diese

      • von /libs/foundation/components/text
      • nach /apps/myProject/components/text

• Anpassen der vom Fehler-Handler angezeigten Seiten

  In diesem Fall wird ein Servlet überlagert:

  • Kopieren Sie im Repository mindestens ein Standardskript:

    • von /libs/sling/servlet/errorhandler/
    • nach /apps/sling/servlet/errorhandler/

Verwendung von JCR-Abfragen und wann diese nicht verwendet werden sollen

JCR-Abfragen sind ein leistungsstarkes Werkzeug, wenn sie richtig eingesetzt werden. Sie eignen sich für:

• echte Endbenutzerabfragen, z. B. Volltextsuchen nach Inhalten.

• Fälle, in denen strukturierte Inhalte im gesamten Repository zu finden sind.

  Stellen Sie in solchen Fällen sicher, dass Abfragen nur bei Bedarf ausgeführt werden. Beispielsweise bei der Aktivierung von Komponenten oder der Cache-Invalidierung (im Gegensatz zu z. B. Workflow-Schritten, Ereignishandlern, die Trigger bei Inhaltsänderungen sind, und Filtern).

Verwenden Sie JCR-Abfragen nie für reine Rendering-Anforderungen. JCR-Abfragen eignen sich beispielsweise nicht für Folgendes:

• Rendering-Navigation
• Erstellen einer Übersicht über die 10 wichtigsten Neuigkeiten
• das Anzeigen der Anzahl von Inhaltselementen

Verwenden Sie zum Rendern von Inhalten den Navigationszugriff auf die Inhaltsstruktur, anstatt eine JCR-Abfrage durchzuführen.

Sicherheitsaspekte

JCR-Sitzungen (Repository)

Verwenden Sie die Benutzersitzung, nicht die Verwaltungssitzung. Sie sollten also Folgendes verwenden:

slingRequest.getResourceResolver().adaptTo(Session.class);

Protect gegen Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) ermöglicht es Angreifern, Code in Webseiten einzufügen, die von anderen Benutzern angesehen werden. Diese Sicherheitslücke kann von böswilligen Webbenutzern ausgenutzt werden, um Zugriffskontrollen zu umgehen.

AEM filtert prinzipiell sämtliche vom Benutzer bereitgestellten Inhalte bei der Ausgabe. Die Prävention von XSS hat sowohl bei der Entwicklung als auch beim Testen höchste Priorität.

Außerdem eine Webanwendungs-Firewall, z. B. mod_security für Apache, kann eine zuverlässige, zentrale Kontrolle über die Sicherheit der Bereitstellungsumgebung bieten und vor zuvor nicht erkannten Cross-Site-Scripting-Angriffen schützen.

Das XSS-API-Cheatsheet enthält Informationen, die Sie benötigen, um die XSS-API zu verwenden und eine AEM App sicherer zu machen. Sie können ihn hier herunterladen:

Das XSSAPI-Cheatsheet.

Datei laden

Sichere Kommunikation für vertrauliche Informationen

Stellen Sie wie bei jeder Internetanwendung sicher, dass beim Transport vertraulicher Informationen

• Datenverkehr über SSL gesichert
• HTTP-POST wird verwendet, falls zutreffend

Dies gilt für Informationen, die vertraulich für das System sind (z. B. Konfiguration oder administrativer Zugriff), sowie für vertrauliche Informationen für die Benutzer (wie ihre persönlichen Daten).

Spezifische Entwicklungsaufgaben

Anpassen von Fehlerseiten

Fehlerseiten können für AEM angepasst werden. Dies ist ratsam, damit die Instanz keine Sling-Traces auf internen Server-Fehlern offenlegt.

Siehe Anpassen der vom Fehler-Handler angezeigten Fehlerseiten für ausführliche Informationen.

Öffnen von Dateien im Java™-Prozess

Da AEM auf viele Dateien zugreifen kann, wird empfohlen, die Anzahl der Dateien für einen Java™-Prozess öffnen explizit für AEM konfiguriert werden.

Um dieses Problem zu minimieren, sollte die Entwicklung sicherstellen, dass geöffnete Dateien ordnungsgemäß geschlossen werden, wenn dies (sinnvoll) möglich ist.

Ressourcen für Business.Adobe.com

Content Insights Customer Communications Mobile Forms Responsive Forms Headless Cms Digital Asset Management