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:
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:
Die folgenden allgemeinen Regeln für Entwickler sind in den meisten gängigen Projekten sinnvoll:
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.
Siehe Verwenden von Überlagerungen für weitere Details.
Beispiel:
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
/libs/foundation/components/text
/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:
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
Sie dürfen keinerlei Änderungen im Pfad /libs
vornehmen.
Der Grund dafür ist, dass der Inhalt von /libs
wird beim nächsten Upgrade Ihrer Instanz überschrieben (und kann auch überschrieben werden, wenn Sie einen Hotfix oder ein Feature Pack anwenden).
Für die Konfiguration und andere Änderungen:
/libs
nach /apps
/apps
vor.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:
Verwenden Sie zum Rendern von Inhalten den Navigationszugriff auf die Inhaltsstruktur, anstatt eine JCR-Abfrage durchzuführen.
Wenn Sie die Query Builderverwenden Sie JCR-Abfragen, da Query Builder JCR-Abfragen im Hintergrund generiert.
Es ist auch sinnvoll, die Sicherheitsprüfliste zu Rate zu ziehen.
Verwenden Sie die Benutzersitzung, nicht die Verwaltungssitzung. Sie sollten also Folgendes verwenden:
slingRequest.getResourceResolver().adaptTo(Session.class);
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.
Der in AEM bereitgestellte Beispiel-Code alleine bietet keinen Schutz vor Angriffen dieser Art, sondern muss durch die Anforderungsfilterung der Firewall in der Web-Anwendung ergänzt werden.
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.
Stellen Sie wie bei jeder Internetanwendung sicher, dass beim Transport vertraulicher Informationen
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).
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.
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.