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: Kopieren Sie also die Definition von /libs
in /apps/<your-project>
. Diese neue Definition in /apps
kann entsprechend Ihren Anforderungen aktualisiert werden.
Einzelheiten finden Sie unter Verwenden von Überlagerungen.
Beispiel:
Dazu gehörte die Überlagerung einer Komponentendefinition:
Erstellen Sie einen neuen Komponentenordner in /apps/<website-name>/components/<MyComponent>
, indem Sie eine vorhandene Komponente kopieren:
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
in /apps
/apps
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 solchen Fällen sicher, dass Abfragen nur ausgeführt werden, wenn dies unbedingt erforderlich ist, z. B. bei Aktivierung oder Cache-Ungültigmachung (im Gegensatz zu Workflows Schritte, Ereignis-Handler, die Trigger bei Inhaltsänderungen, Filtern usw. sind).
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 lohnt sich auch, auf die Sicherheits-Checkliste zu verweisen.
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.
Darüber hinaus kann eine Web-Anwendungs-Firewall, wie z. B. mod_security for Apache, eine zuverlässige und zentrale Kontrolle über die Sicherheit der Bereitstellungs-Umgebung bieten und vor zuvor unentdeckten Cross-Site-Scripting-Angriffen schützen.
Der in AEM bereitgestellte Beispielcode 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.