AEM 6.4 a atteint la fin de la prise en charge étendue et cette documentation n’est plus mise à jour. Pour plus d’informations, voir notre période de support technique. Rechercher les versions prises en charge here.
Les composants et les modèles AEM représentent un ensemble d’outils très puissants. Ils peuvent être utilisés par les développeurs pour offrir aux utilisateurs, éditeurs et administrateurs de sites web la possibilité d’adapter leurs sites web aux besoins changeants de l’entreprise (agilité du contenu) tout en conservant la disposition uniforme des sites (protection de la marque).
Un défi classique pour une personne responsable d’un site web, ou d’un ensemble de sites web (par exemple dans une succursale d’une entreprise globale), est d’introduire un nouveau type de présentation de contenu sur leurs sites web.
Supposons qu’il soit nécessaire d’ajouter une page de liste de discussion aux sites web, qui répertorie des extraits d’autres articles déjà publiés. La page doit avoir la même conception et la même structure que le reste du site web.
La méthode recommandée pour résoudre un tel problème serait la suivante :
Cela illustre la manière dont cette approche permet aux utilisateurs et aux administrateurs du site web de répondre rapidement aux besoins de l’entreprise, sans avoir à faire appel aux équipes de développement. Les autres méthodes, telles que la création d’un modèle, sont généralement coûteuses, car elles nécessitent un processus de gestion du changement et la participation de l’équipe de développement. Cela rend le processus entier beaucoup plus long et coûteux.
Les développeurs de systèmes basés sur AEM doivent donc utiliser :
Les règles générales suivantes s’appliquent aux développeurs dans la plupart des projets habituels :
Lors de la création de vos propres composants ou de la personnalisation d’un composant existant, il est souvent plus facile (et plus sûr) de réutiliser des définitions existantes. Les mêmes principes s’appliquent également à d’autres éléments dans AEM, par exemple le gestionnaire d’erreurs.
Cela peut être effectué en copiant et en remplaçant la définition existante. En d’autres termes, en copiant la définition de /libs
vers /apps/<your-project>
. Cette nouvelle définition, dans /apps
, peut être mise à jour en fonction de vos besoins.
Voir Utilisation des recouvrements pour plus d’informations.
Par exemple :
Personnalisation d’un composant
Cette procédure suppose de superposer une définition de composant :
Créez un dossier de composants dans /apps/<website-name>/components/<MyComponent>
en copiant un composant existant :
Par exemple, pour personnaliser le composant Texte, copiez :
/libs/foundation/components/text
/apps/myProject/components/text
Personnalisation des pages affichées par le gestionnaire d’erreurs
Ce cas implique le recouvrement d’un servlet :
Dans le référentiel, copiez le ou les scripts par défaut :
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
Vous ne devez rien modifier dans le chemin /libs
.
En effet, le contenu de /libs
est remplacé dès que vous mettez à niveau votre instance (et risque de l’être si vous appliquez un correctif ou un pack de fonctionnalités).
Pour la configuration et les autres modifications :
/libs
vers /apps
;/apps
.Lorsqu’elles sont utilisées correctement, les requêtes JCR sont un puissant outil. Elles sont adaptées aux éléments suivants :
requêtes réelles de l’utilisateur final, telles que les recherches de texte intégral sur le contenu.
les cas où du contenu structuré doit être trouvé dans l’ensemble du référentiel.
Dans de tels cas, assurez-vous que les requêtes ne s’exécutent que lorsqu’elles sont absolument nécessaires, par exemple, lors de l’activation d’un composant ou de l’invalidation du cache (par opposition, par exemple, aux étapes de workflows, aux gestionnaires d’événement qui se déclenchent lors des modifications de contenu, aux filtres, etc.).
Les requêtes JCR ne doivent jamais être utilisées pour les requêtes de rendu pures. Par exemple, les requêtes JCR ne sont pas appropriées pour
Pour le rendu du contenu, utilisez l’accès de navigation à l’arborescence de contenu au lieu d’effectuer une requête JCR.
Si vous utilisez la variable Query Builder, vous utilisez des requêtes JCR, car Query Builder génère des requêtes JCR en arrière-plan.
Il est également recommandé de se reporter à la liste de contrôle de sécurité.
Vous devez utiliser la session utilisateur, et non la session d’administration. Cela signifie que vous devez utiliser :
slingRequest.getResourceResolver().adaptTo(Session.class);
Les scripts de site à site (XSS) permettent aux pirates d’injecter du code dans des pages web consultées par d’autres utilisateurs. Cette vulnérabilité de sécurité peut être exploitée par des utilisateurs web malveillants pour contourner les contrôles d’accès.
AEM applique le principe de filtrage de tout le contenu fourni par l’utilisateur en sortie. La prévention de XSS est prioritaire lors des phases de développement et de test.
En outre, un pare-feu d’application Web, tel que mod_security pour Apache, peut fournir un contrôle centralisé fiable sur la sécurité de l’environnement de déploiement, ainsi qu’une protection contre les attaques XSS qui n’étaient pas détectées précédemment.
L’exemple de code fourni avec AEM peut ne pas être protégé contre de telles attaques et repose généralement sur le filtrage des requêtes par un pare-feu d’application web.
L’aide-mémoire de l’API XSS contient les informations dont vous avez besoin pour utiliser l’API XSS et renforcer la sécurité d’une application AEM. Vous pouvez le télécharger ici :
Aide-mémoire de XSSAPI.
Pour toute application Internet, assurez-vous que lors du transport d’informations confidentielles
Cela s’applique aux informations confidentielles du système (telles que la configuration ou l’accès administratif) ainsi qu’aux informations confidentielles de ses utilisateurs (telles que leurs informations personnelles).
Les pages d’erreur peuvent être personnalisées pour AEM. Ceci est recommandé afin que l’instance ne révèle pas de traces sling sur les erreurs du serveur interne.
Voir Personnalisation des pages d’erreur affichées par le gestionnaire d’erreurs pour plus d’informations.
Étant donné qu’AEM peut accéder à un grand nombre de fichiers, il est recommandé que le nombre de fichiers ouverts pour un processus Java soit configuré explicitement pour AEM.
Pour minimiser ce problème, vous devriez vous assurer lors du développement que tout fichier ouvert est correctement fermé dès que possible (de manière raisonnable).