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 afin de fournir aux utilisateurs, éditeurs et administrateurs de sites web la capacité d’adapter leurs sites web en fonction de l’évolution des besoins de l’entreprise (agilité du contenu) tout en conservant la mise en page uniforme des sites (protection de la marque).
Pour une personne chargée d’un site web ou d’un ensemble de sites web (par exemple, dans une succursale d’une entreprise globale), il est souvent difficile d’introduire un nouveau type de présentation de contenu sur sess sites web.
Supposons qu’il soit nécessaire d’ajouter sur les sites web une page de liste d’actualités qui répertorie des extraits d’autres articles déjà publiés. La page doit avoir la même conception et structure que le reste du site web.
La méthode recommandée pour y arriver consiste à :
Cela illustre comment cette approche permet aux administrateurs et aux utilisateurs contribuant au site web de répondre aux besoins de leur entreprise rapidement, sans impliquer les équipes de développement. Les méthodes alternatives, telles que la création d’un modèle, sont généralement coûteuses, car elles requièrent un processus de gestion de modification et la participation de l’équipe de développement. Cela rend le processus beaucoup plus long et coûteux.
Les développeurs des systèmes basés sur AEM doivent donc utiliser :
Les règles générales suivantes sont pertinentes pour les développeurs dans la majorité des projets habituels :
Lors de la création de vos propres composants ou de la personnalisation d’un composant existant, il est souvent plus simple (et plus sûr) de recycler les 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 de détails.
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 conviennent aux :
requêtes des utilisateurs finaux, telles que les recherches en texte intégral sur le contenu ;
les occasions où le contenu structuré doit pouvoir être recherché sur le référentiel entier.
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 devraient jamais être employées pour des requêtes de rendu pures. Par exemple, les requêtes JCR ne sont pas utiles pour :
Pour effectuer 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 Query Builder, vous utilisez des requêtes JCR, car Query Builder génère des requêtes JCR en interne.
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 administrative. Cela signifie que vous devriez 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 faille de sécurité peut être exploitée par des internautes malveillants pour contourner les contrôles d’accès.
AEM applique le principe de filtrage de l’ensemble du contenu fourni par l’utilisateur lors de la sortie. La prévention du script intersite (XSS) se voit accorder la priorité la plus élevée 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 protéger contre de telles attaques et repose généralement sur le filtrage des requêtes par un pare-feu pour applications 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 :
L’aide-mémoire de l’API XSS.
Comme pour toute application Internet, lors du transport d’informations confidentielles, vérifiez que :
Cela s’applique aux informations confidentielles au sein du système (comme la configuration ou l’accès administrateur), ainsi qu’aux informations confidentielles pour ses utilisateurs (comme leurs détails personnels).
Les pages d’erreur peuvent être personnalisées pour AEM. Cela est recommandé de sorte que l’instance ne révèle pas de traces Sling sur les erreurs de serveur interne.
Voir Personnalisation des pages d’erreur affichées par le gestionnaire d’erreur pour plus de détails.
É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).