AEM-Komponenten und -vorlagen sind sehr effiziente Tools. Entwickler können sie zum Bereitstellen von Websites für Geschäftsbenutzer, Editoren und Administratoren verwenden. Dabei sind Funktionen verfügbar, mit denen sie Websites an die sich ändernden Geschäftsanforderungen anpassen können (Inhaltsagilität), ohne das einheitliche Layout der Sites zu ändern (Markenschutz).
Eine typische Herausforderung für die für eine oder mehrere Websites (z. B. in einer Zweigniederlassung eines globalen Unternehmens) verantwortliche Person ist die Einführung einer neuen Art von Inhaltspräsentation auf den Websites.
Angenommen, eine Newslisten-Seite, die Auszüge aus bereits veröffentlichten Artikeln enthält, muss zu den Websites hinzugefügt werden. Die Seite soll das gleiche Design und die gleiche Struktur wie der Rest der Website haben.
Es wird empfohlen, wie folgt an diese Herausforderung heranzugehen:
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. Andere Methoden, wie das Erstellen einer neuen Vorlage, sind in der Regel kostenintensiv. Außerdem sind dafür ein Änderungsmanagementprozess und die Beteiligung des Entwicklungsteams erforderlich. Dadurch wird der gesamte Prozess wesentlich länger und teurer.
Entwickler von AEM-basierten Systemen sollten daher Folgendes verwenden:
Die folgenden allgemeinen Regeln für Entwickler sind in der Mehrzahl gängiger Projekte sinnvoll:
Wenn Sie eigene Komponenten erstellen oder eine vorhandene Komponente anpassen, ist es häufig am einfachsten (und sichersten), vorhandene Definitionen wiederzuverwenden. Dies gilt auch für andere Elemente in AEM, zum Beispiel für 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.
Einzelheiten finden Sie unter Verwenden von Überlagerungen.
Beispiel:
Dazu gehörte das Überlagern einer Komponentendefinition:
Erstellen Siedurch Kopieren einer vorhandenen Komponente einen neuen Komponentenordner in /apps/<website-name>/components/<MyComponent>
:
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 das/die Standardskript(e):
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
Sie dürfen keinerlei Änderungen im Pfad /libs
vornehmen.
da der Inhalt von /libs
überschrieben wird, wenn Sie die Instanz das nächste Mal aktualisieren. (Außerdem kann der Inhalt auch durch Anwenden von Hotfixes oder Feature Packs überschrieben werden.)
Für die Konfiguration und andere Änderungen:
/libs
nach /apps
/apps
vor.JCR-Abfragen sind sehr wirksam, wenn sie richtig eingesetzt werden. Sie sind besonders geeignet für:
echte Benutzerabfragen, wie die Volltextsuche in Inhalten.
die Suche nach strukturierten Inhalten in einem gesamten Repository.
Stellen Sie in diesen Fällen sicher, dass Abfragen nur ausgeführt werden, wenn unbedingt notwendig, z. B. bei Aktivierung einer Komponente oder Ungültigmachen eines Cache (jedoch nicht bei Workflow-Schritten, bei durch Inhaltsänderungen ausgelösten Ereignis-Handlern, Filtern usw.).
JCR-Abfragen sollten nicht für reine Rendering-Anforderungen verwendet werden. Beispielsweise sind JCR-Abfragen nicht geeignet für
Verwenden Sie für das Rendern von Inhalten anstelle einer JCR-Abfrage den Navigationszugriff auf die Inhaltsstruktur.
Beim Verwenden von Query Builder verwenden Sie jedoch JCR-Abfragen, da Query Builder JCR-Abfragen im Hintergrund erzeugt.
Es ist auch sinnvoll, die Sicherheitsprüfliste zu Rate zu ziehen.
Verwenden Sie die Benutzersitzung und nicht die Administratorsitzung. Sie sollten also Folgendes verwenden:
slingRequest.getResourceResolver().adaptTo(Session.class);
Mit Cross-Site Scripting (XSS) können Angreifer Code in Webseiten einfügen, die von anderen Benutzern aufgerufen werden. Diese Sicherheitslücke kann von böswilligen Nutzern ausgenutzt werden, um die Zugriffssteuerung zu umgehen.
AEM filtert prinzipiell sämtliche vom Benutzer bereitgestellten Inhalte bei der Ausgabe. Bei Entwicklung und Tests hat das Vermeiden von XSS höchste Priorität.
Zusätzlich kann eine Firewall in der Web-Anwendung wie mod_security für Apache die Sicherheit einer Entwicklungsumgebung zuverlässig und zentral steuern und diese vor bisher unerkannten 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.
Der XSS-API-Spickzettel enthält Informationen, die Sie für das Verwenden der XSS-API und Sichern einer AEM-Anwendung benötigen. Sie können diesen hier herunterladen:
Der XSSAPI-Spickzettel.
Stellen Sie wie auch bei anderen Internetanwendungen sicher, dass bei der Übertragung vertraulicher Informationen
Dies gilt für vertrauliche Systeminformationen (wie Konfiguration oder Administrationszugriff) und vertrauliche Benutzerinformationen (wie persönliche Daten).
Fehlerseiten können in AEM angepasst werden. Dies ist ratsam, um zu vermeiden, dass die Instanz Sling-Ablaufverfolgungen zu internen Serverfehlern ausgibt.
Weitere Informationen finden Sie unter Anpassen der vom Fehler-Handler angezeigten Seiten.
Da AEM auf eine große Anzahl von Dateien zugreifen kann, wird empfohlen, die Anzahl geöffneter Dateien für einen Java-Prozess ausdrücklich für AEM zu konfigurieren.
Um das Problem gering zu halten, sollte bei der Entwicklung darauf geachtet werden, dass geöffnete Dateien so schnell wie irgend möglich richtig geschlossen werden.