Componentes e modelos do AEM formam um kit de ferramentas muito eficiente. Eles podem ser usados pelos desenvolvedores para fornecer aos usuários empresariais, editores e administradores de sites a funcionalidade de adaptar seus sites às necessidades comerciais em constante mudança (agilidade do conteúdo), além de manter o layout uniforme dos sites (proteção da marca).
Um desafio típico para uma pessoa responsável por um site, ou conjunto de sites (por exemplo, em uma filial de uma empresa global), é introduzir um novo tipo de apresentação de conteúdo em seus sites.
Suponhamos que seja necessário adicionar uma página de lista de notícias aos sites, que lista extratos de outros artigos já publicados. A página deve ter o mesmo design e estrutura que o restante do site.
A maneira recomendada de abordar esse desafio seria:
Isso ilustra como essa abordagem permite que os usuários e administradores contribuintes do site respondam rapidamente às necessidades comerciais, sem exigir o envolvimento de equipes de desenvolvimento. Métodos alternativos, como a criação de um novo modelo, geralmente são um exercício dispendioso, exigindo um processo de gerenciamento de alterações e o envolvimento da equipe de desenvolvimento. Isso torna todo o processo muito mais longo e caro.
Por conseguinte, os criadores de sistemas baseados no AEM devem utilizar:
As seguintes regras gerais para desenvolvedores fazem sentido na maioria dos projetos comuns:
Ao criar seus próprios componentes ou personalizar um componente existente, geralmente é mais fácil (e mais seguro) reutilizar as definições existentes. Os mesmos princípios também se aplicam a outros elementos dentro do AEM, por exemplo, o manipulador de erros.
Isso pode ser feito copiando e sobrepondo a definição existente. Em outras palavras, copiar a definição de /libs
para /apps/<your-project>
. Esta nova definição, em especial /apps
, podem ser atualizados de acordo com suas necessidades.
Consulte Uso de sobreposições para obter mais detalhes.
Por exemplo:
Personalização de um componente
Isso envolvia a sobreposição de uma definição de componente:
Criar uma nova pasta de componentes no /apps/<website-name>/components/<MyComponent>
copiando um componente existente:
Por exemplo, para personalizar a cópia do componente de Texto:
/libs/foundation/components/text
/apps/myProject/components/text
Personalização de páginas mostradas pelo Manipulador de erros
Esse caso envolve a sobreposição de um servlet:
No repositório, copie o(s) script(s) padrão:
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
Você não deve alterar qualquer item no /libs
caminho.
Isso ocorre porque o conteúdo de /libs
é substituído na próxima vez que você atualizar sua instância (e pode ser substituído ao aplicar um hotfix ou pacote de recursos).
Para configuração e outras alterações:
/libs
para /apps
/apps
As consultas JCR são uma ferramenta poderosa quando empregadas corretamente. Eles são adequados para:
consultas reais de usuários finais, como pesquisas de texto completo sobre conteúdo.
ocasiões em que o conteúdo estruturado precisa ser encontrado em todo o repositório.
Nesses casos, verifique se as consultas são executadas somente quando absolutamente necessário, por exemplo, na ativação de componentes ou na invalidação de cache (em vez de Etapas de fluxos de trabalho, Manipuladores de eventos que acionam modificações de conteúdo, Filtros, etc.).
As consultas JCR nunca devem ser usadas para solicitações de renderização puras. Por exemplo, consultas JCR não são apropriadas para
Para renderizar conteúdo, use o acesso de navegação à árvore de conteúdo em vez de executar uma consulta JCR.
Se você usar o Construtor de consulta, você usa Consultas JCR, já que o Construtor de consultas gera Consultas JCR por baixo dos panos.
É igualmente útil fazer referência lista de verificação de segurança.
Você deve usar a sessão do usuário, não a sessão administrativa. Isso significa que você deve usar:
slingRequest.getResourceResolver().adaptTo(Session.class);
A criação de script entre sites (XSS) permite que invasores injetem código em páginas da Web visualizadas por outros usuários. Essa vulnerabilidade de segurança pode ser explorada por usuários mal-intencionados da Web para ignorar controles de acesso.
O AEM aplica o princípio de filtrar todo o conteúdo fornecido pelo usuário na saída. É dada a maior prioridade à prevenção de XSS durante o desenvolvimento e o teste.
Além disso, um firewall de aplicativo web, como mod_security para ApacheO, oferece controle confiável e central sobre a segurança do ambiente de implantação e proteção contra ataques de script entre sites não detectados anteriormente.
O código de exemplo fornecido com o AEM pode não proteger contra esses ataques e geralmente depende da filtragem de solicitações por um firewall de aplicativo da Web.
A folha de características da API XSS contém informações que você precisa saber para usar a API XSS e tornar um aplicativo AEM mais seguro. Você pode baixá-lo aqui:
A folha de características do XSSAPI.
Quanto a qualquer aplicativo da Internet, certifique-se de que, ao transportar informações confidenciais
Isso se aplica a informações confidenciais para o sistema (como configuração ou acesso administrativo), bem como informações confidenciais para seus usuários (como seus detalhes pessoais)
As páginas de erro podem ser personalizadas para AEM. Isso é aconselhável para que a instância não revele rastreamentos sling em erros internos do servidor.
Consulte Personalização de páginas de erro mostradas pelo Manipulador de erros para obter detalhes completos.
Como o AEM pode acessar um grande número de arquivos, recomenda-se que o número de abrir arquivos para um processo Java ser configurados explicitamente para AEM.
Para minimizar esse problema, o desenvolvimento deve garantir que qualquer arquivo aberto seja fechado corretamente assim que (de forma significativa) possível.