Adobe Experience Manager (AEM) komponenter och mallar utgör en kraftfull verktygslåda. De kan användas av utvecklare för att ge användare, redaktörer och administratörer på webbplatser möjlighet att anpassa sina webbplatser efter förändrade affärsbehov (innehållsflexibilitet). Allt detta med bibehållen enhetlig layout för webbplatserna (varumärkesskydd).
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 mall, är vanligtvis en kostsam övning som kräver en ändringshanteringsprocess och att utvecklingsteamet är engagerat. Detta gör hela processen längre och kostsam.
Utvecklarna av AEM bör därför använda
Följande allmänna regler för utvecklare passar bäst i de vanligaste projekten:
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 för 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 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 ett eller flera standardskript i databasen:
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
Gör inte ändra något i /libs
bana.
Orsaken är att innehållet i /libs
skrivs över nästa gång du uppgraderar din instans (och kan mycket väl skrivas över när du installerar 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å fall måste du se till att frågor bara körs när det behövs. Till exempel vid komponentaktivering eller cacheogiltigförklaring (till skillnad från till exempel arbetsflöden, händelsehanterare som aktiveras vid innehållsändringar och filter).
Använd aldrig JCR-frågor för renderingsbegäranden. JCR-frågor passar till exempel inte för följande:
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 Frågebyggarenanvä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.
Använd 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.
En brandvägg för webbprogram, som mod_security för Apache, kan ge tillförlitlig och 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 måste 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-kalkylblad.
Liksom för alla Internetprogram ska du se till att konfidentiella uppgifter skickas
Detta gäller information som är konfidentiell för systemet (som konfiguration eller administrativ åtkomst) och information som är konfidentiell för användarna (som deras 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 många filer bör du ange antalet öppna filer för en Java™-process vara explicit konfigurerad för AEM.
För att minimera problemet bör utvecklingsverktyget se till att alla öppna filer stängs korrekt när det är möjligt (meningsfullt).