AEM componentes e modelos formam um kit de ferramentas muito poderoso. Eles podem ser usados por desenvolvedores para fornecer aos usuários empresariais, editores e administradores do site a funcionalidade de adaptar seus sites às necessidades comerciais em mudança (agilidade de conteúdo) e, ao mesmo tempo, 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 newslist aos websites, que lista extratos de outros artigos já publicados. A página deve ter o mesmo design e estrutura que o restante do site.
A forma recomendada de abordar este desafio seria:
Isso ilustra como essa abordagem permite que os usuários e administradores do site que contribuem respondam às necessidades dos negócios rapidamente, sem a necessidade do envolvimento das equipes de desenvolvimento. Os métodos alternativos, como a criação de um novo modelo, são geralmente um exercício dispendioso, exigindo um processo de gerenciamento de alterações e envolvimento da equipe de desenvolvimento. Isto torna todo o processo muito mais longo e dispendioso.
Os desenvolvedores de sistemas baseados em AEM devem, por conseguinte, utilizar:
As seguintes regras gerais para os desenvolvedores fazem sentido na maioria dos projetos habituais:
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>
. Essa nova definição, em /apps
, pode ser atualizada de acordo com seus requisitos.
Consulte Usando Sobreposições para obter mais detalhes.
Por exemplo:
Personalização de um componente
Isso envolveu sobrepor uma definição de componente:
Crie uma nova pasta de componentes em /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 sobreposição de um servlet:
No repositório, copie os scripts padrão:
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
Você não deve alterar nada no caminho /libs
.
Isso ocorre porque o conteúdo de /libs
é substituído na próxima vez que você atualizar sua instância (e pode muito bem ser substituído quando você aplicar uma correção ou um pacote de recursos).
Para configurações e outras alterações:
/libs
para /apps
/apps
Os Query JCR são uma ferramenta poderosa quando empregados corretamente. São adequados para:
query reais do usuário final, como pesquisas de texto completo no conteúdo.
ocasiões em que o conteúdo estruturado precisa ser encontrado em todo o repositório.
Nesses casos, verifique se os query só são executados quando absolutamente necessário, por exemplo, na ativação do componente ou na invalidação do cache (em vez de, por exemplo, Etapas do Workflows, Manipuladores de Evento que acionam modificações de conteúdo, Filtros etc).
Os Query JCR nunca devem ser usados para solicitações de renderização pura. Por exemplo, Query JCR não são apropriados para
Para renderizar conteúdo, use o acesso de navegação à árvore de conteúdo em vez de executar um Query JCR.
Se você usar o Construtor de Query, usará Query JCR, já que o Construtor de Query gera Query JCR sob o capô.
Também vale a pena 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);
Scripts entre sites (XSS) permitem que os 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 maliciosos da Web para ignorar controles de acesso.
AEM aplica o princípio de filtrar todo o conteúdo fornecido pelo usuário na saída. A prevenção do XSS é atribuída à prioridade mais alta durante o desenvolvimento e o teste.
Além disso, um firewall de aplicativo da Web, como mod_security para Apache, pode fornecer controle central e confiável sobre a segurança do ambiente de implantação e proteger contra ataques de script entre sites não detectados anteriormente.
O exemplo de código fornecido com AEM pode não proteger contra tais ataques e geralmente depende da filtragem de solicitações por um firewall de aplicativos da Web.
A folha de verificação 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 truques XSSAPI.
Quanto a qualquer pedido de acesso à Internet, certifique-se de que, ao transportar informações confidenciais,
Isso se aplica às informações confidenciais do sistema (como configuração ou acesso administrativo), bem como às informações confidenciais dos usuários (como seus detalhes pessoais)
As páginas de erro podem ser personalizadas para AEM. Isso é recomendável para que a instância não revele rastreamentos sling em erros internos do servidor.
Consulte Personalizando páginas de erro mostradas pelo Manipulador de erros para obter detalhes completos.
Como AEM pode acessar um grande número de arquivos, recomenda-se que o número de arquivos abertos para um processo Java seja configurado explicitamente para AEM.
Para minimizar esse problema, o desenvolvimento deve garantir que todos os arquivos abertos sejam fechados corretamente assim que possível (significativo).