AEM components and templates form a very powerful toolkit. They can be used by developers to provide website business users, editors, and administrators with the functionality to adapt their websites to changing business needs (content agility) while retaining the uniform layout of the sites (brand protection).
A typical challenge for a person responsible for a website, or set of websites (for example in a branch office of a global enterprise), is to introduce a new type of content presentation on their websites.
Let us assume there is a need to add a newslist page to the websites, which lists extracts from other articles already published. The page should have the same design and structure as the rest of the website.
The recommended way to approach such a challenge would be to:
This illustrates how this approach empowers the contributing users and administrators of the website to respond to business needs quickly, without requiring the involvement of development teams. Alternative methods, such as creating a new template, is usually a costly exercise, requiring a change management process and involvement of the development team. This makes the whole process much longer and costly.
The developers of AEM-based systems should therefore use:
The following general rules for developers make sense in majority of usual projects:
When creating your own components or customizing an existing component it is often easiest (and safest) to re-use existing definitions. The same principles also applies to other elements within AEM, for example the error handler.
This can be done by copying and overlaying the existing definition. In other words, copying the definition from /libs
to /apps/<your-project>
. This new definition, in /apps
, can be updated according to your requirements.
See Using Overlays for more details.
For example:
This involved overlaying a component definition:
Create a new component folder in /apps/<website-name>/components/<MyComponent>
by copying an existing component:
For example, to customize the Text component copy:
/libs/foundation/components/text
/apps/myProject/components/text
Customizing pages shown by the Error Handler
This case involves overlaying a servlet:
In the repository, copy the default script(s):
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
You must not change anything in the /libs
path.
This is because the content of /libs
is overwritten the next time you upgrade your instance (and may well be overwritten when you apply either a hotfix or feature pack).
For configuration and other changes:
/libs
to /apps
/apps
JCR Queries are a powerful tool when employed correctly. They are appropriate for:
real end-user queries, such as fulltext searches on content.
occasions where structured content needs to be found across the entire repository.
In such cases, make sure that queries only run when absolutely required, e.g. on component activation or cache invalidation (as opposed to e.g. Workflows Steps, Event Handlers that trigger on content modifications, Filters, etc).
JCR Queries should never be used for pure rendering requests. For example, JCR Queries are not appropriate for
For rendering content, use navigational access to the content tree instead of performing a JCR Query.
If you use the Query Builder, you use JCR Queries, as the Query Builder generates JCR Queries under the hood.
It is also worthwhile to reference the security checklist.
You should use the user session, not the administrative session. This means you should use:
slingRequest.getResourceResolver().adaptTo(Session.class);
Cross-site scripting (XSS) allows attackers to inject code into web pages viewed by other users. This security vulnerability can be exploited by malicious web users to bypass access controls.
AEM applies the principle of filtering all user-supplied content upon output. Preventing XSS is given the highest priority during both development and testing.
Additionally, a web application firewall, such as mod_security for Apache, can provide reliable, central control over the security of the deployment environment and protect against previously undetected cross-site scripting attacks.
Example code provided with AEM may not itself protect against such attacks and generally relies on request filtering by a web application firewall.
The XSS API cheat sheet contains information you need to know in order to use the XSS API and make an AEM app more secure. You can download it here:
The XSSAPI cheat sheet.
As for any internet application, make sure that when transporting confidential information
This applies to information that is confidential to the system (like configuration or administrative access) as well as information confidential to its users (like their personal details)
Error pages can be customized for AEM. This is advisable so that the instance does not reveal sling traces on internal server errors.
See Customizing Error Pages shown by the Error Handler for full details.
Because AEM can access a large number of files it is recommended that the number of open files for a Java process be explicitly configured for AEM.
To minimize this issue development should ensure that any file opened is correctly closed as soon as (meaningfully) possible.