AEM komponenter och mallar utgör en mycket kraftfull verktygslåda. De kan användas av utvecklare för att ge användare, redaktörer och administratörer på webbplatser den funktionalitet de behöver för att anpassa sina webbplatser till föränderliga affärsbehov (innehållsflexibilitet) samtidigt som webbplatsernas enhetliga layout (varumärkesskydd) bibehålls.
En typisk utmaning för en person som ansvarar för en webbplats, eller en uppsättning webbplatser (till exempel på ett globalt företags kontor) är att presentera en ny typ av innehållspresentation på deras webbplatser.
Låt oss anta att det finns ett behov av att lägga till en nyhetslistsida på webbplatserna, som listar utdrag från andra artiklar som redan har publicerats. Sidan ska ha samma design och struktur som resten av webbplatsen.
Det rekommenderade sättet att hantera en sådan utmaning är att
Detta visar hur detta tillvägagångssätt gör det möjligt för de medverkande användarna och administratörerna på webbplatsen att snabbt reagera på affärsbehov, utan att utvecklingsteamen behöver vara engagerade. Alternativa metoder, till exempel att skapa en ny mall, är vanligtvis en kostsam övning som kräver en ändringshanteringsprocess och att utvecklingsteamet är engagerat. Detta gör hela processen mycket längre och kostsam.
Utvecklarna av AEM bör därför använda
Följande allmänna regler för utvecklare är bra för de flesta vanliga projekt:
När du skapar egna komponenter eller anpassar en befintlig komponent är det oftast enklast (och säkraste) att återanvända befintliga definitioner. Samma principer gäller även andra element i AEM, till exempel felhanteraren.
Detta kan du göra genom att kopiera och ersätta den befintliga definitionen. Med andra ord, kopiera definitionen från /libs
till /apps/<your-project>
. Den här nya definitionen, i /apps
, kan uppdateras efter dina behov.
Se Använda övertäckningar för mer information.
Till exempel:
Detta innebar att en komponentdefinition skulle ersättas:
Skapa en ny komponentmapp i /apps/<website-name>/components/<MyComponent>
genom att kopiera en befintlig komponent:
Så här anpassar du komponentkopian Text:
/libs/foundation/components/text
/apps/myProject/components/text
Anpassa sidor som visas av felhanteraren
Det här fallet handlar om att täcka över en serverdel:
Kopiera standardskripten i databasen:
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
Du får inte ändra något i /libs
bana.
Detta beror på innehållet i /libs
skrivs över nästa gång du uppgraderar din instans (och kan mycket väl skrivas över när du använder en snabbkorrigering eller ett funktionspaket).
För konfiguration och andra ändringar:
/libs
till /apps
/apps
JCR-frågor är ett kraftfullt verktyg när de används på rätt sätt. De är lämpliga för
riktiga slutanvändarfrågor, t.ex. fulltextsökningar i innehåll.
tillfällen då strukturerat innehåll måste hittas i hela databasen.
I sådana fall ska du se till att frågor endast körs när det är absolut nödvändigt, t.ex. vid komponentaktivering eller cacheogiltigförklaring (till skillnad från t.ex. arbetsflödessteg, händelsehanterare som utlöser vid innehållsändringar, filter etc.).
JCR-frågor ska aldrig användas för renderingsbegäranden. JCR-frågor passar till exempel inte för
Använd navigeringsåtkomst till innehållsträdet i stället för att utföra en JCR-fråga när du återger innehåll.
Om du använder Query Builderanvänder du JCR-frågor när Query Builder genererar JCR-frågor under huven.
Det är även värt att hänvisa till checklista för säkerhet.
Du bör använda användarsessionen, inte den administrativa sessionen. Detta innebär att du bör använda:
slingRequest.getResourceResolver().adaptTo(Session.class);
Med XSS (Cross-site scripting) kan angripare lägga in kod på webbsidor som visas av andra användare. Säkerhetsluckan kan utnyttjas av skadliga webbanvändare för att kringgå åtkomstkontroller.
AEM tillämpar principen om att filtrera allt innehåll som användaren tillhandahåller vid utskrift. Förhindrande av XSS har högsta prioritet under både utveckling och testning.
Dessutom en brandvägg för webbprogram, som mod_security för Apache, kan ge tillförlitlig, central kontroll över distributionsmiljöns säkerhet och skydda mot tidigare oidentifierade serveröverskridande skriptattacker (cross-site scripting).
Exempelkod som medföljer AEM kan inte skydda sig mot sådana attacker och är vanligtvis beroende av att en webbprogrambrandvägg filtrerar begäranden.
XSS API-databladet innehåller information som du behöver känna till för att kunna använda XSS API:t och göra en AEM säkrare. Du kan ladda ned den här:
XSSAPI-kalkylbladet.
Liksom för alla Internetprogram ska du se till att konfidentiella uppgifter skickas
Detta gäller information som är konfidentiell för systemet (t.ex. konfiguration eller administrativ åtkomst) samt information som är konfidentiell för användarna (t.ex. personuppgifter)
Felsidor kan anpassas för AEM. Detta är tillrådligt så att instansen inte visar slingspår på interna serverfel.
Se Anpassa felsidor som visas av felhanteraren för fullständig information.
Eftersom AEM kan få åtkomst till ett stort antal filer rekommenderar vi att man öppna filer för en Java-process vara explicit konfigurerad för AEM.
För att minimera problemet bör du se till att alla öppnade filer stängs korrekt så snart som (meningsfullt) möjligt.