URLs personalizados do Dispatcher | AEM

Este documento ajudará você a entender como o Adobe Experience Manager lida com URLs personalizados e técnicas adicionais, como o uso de regras de regravação para aproximar o conteúdo da borda do delivery.

Descrição description

Ambiente

Adobe Experience Manager

Problemas/Sintomas

Como o AEM lida com urls personalizados? Existem técnicas adicionais para mapear o conteúdo mais próximo da borda do delivery?

O que são URLs personalizados?

Quando você tem conteúdo em uma estrutura de pastas lógica, ele nem sempre está em um URL de fácil referência. URLs personalizados são como atalhos. URLs menores ou exclusivos que fazem referência ao local em que o conteúdo real está.

Um exemplo: /about apontou para /content/we-retail/us/en/about-us.html

Os autores do AEM têm a opção de definir propriedades de url personalizado em um conteúdo no AEM e publicá-lo.

Para que esse recurso funcione, você precisará ajustar os filtros do dispatcher para permitir a personalização. Isso não é aceitável para ajustar os arquivos de configuração do Dispatcher na taxa que os autores precisariam para configurar essas entradas de página personalizada.

Por esse motivo, o módulo Dispatcher tem um recurso para permitir automaticamente qualquer item listado como personalizado na árvore de conteúdo.

Resolução resolution

Como funciona?

Criação de URLs personalizados

O autor visita uma página no AEM e visita as propriedades da página e adiciona as entradas na seção url personalizado.

Depois que elas salvam as alterações e ativam a página, a personalização é atribuída a esta página.

Interface para toque:

Localizador de Conteúdo Clássico:

Observação: saiba que isso é muito vulnerável a problemas de namespace. As entradas personalizadas são globais para todas as páginas; essa é apenas uma das deficiências para as quais você deve planejar soluções alternativas. Explicaremos algumas delas mais tarde.

Resolução/Mapeamento de Recursos:

Cada entrada personalizada é uma entrada de mapa sling para um redirecionamento interno. Esses mapas são visíveis no console Felix de instâncias do AEM (/system/console/jcrresolver)

Esta é uma captura de tela de uma entrada de mapa criada por uma entrada personalizada:

No exemplo acima, quando solicitamos à instância AEM que visite /aboutus, ele resolverá para /content/we-retail/us/en/about-us.html

filtros de permissão automática do Dispatcher:

O Dispatcher em um estado seguro filtra solicitações no caminho/por meio do Dispatcher, pois essa é a raiz da árvore do JCR.

É importante garantir que os editores só estejam permitindo o conteúdo do /content e outros caminhos seguros etc… e não caminhos como /system etc.

Aqui estão os urls personalizados na pasta base de /, então, como permitimos que eles alcancem os editores enquanto permanecem seguros?

O Dispatcher simples tem um mecanismo de permissão de filtro automático e você precisa instalar um pacote AEM e configurar o Dispatcher para apontar para a página desses pacotes. Visite aqui para ver o pacote AEM.

O Dispatcher tem uma seção de configuração em seu arquivo farm:

/vanity_urls {      /url    "/libs/granite/dispatcher/content/vanityUrls.html"
  /file   "/tmp/vanity_urls"      /delay  300 }

Essa configuração instrui o Dispatcher a buscar esse URL da instância AEM que ele envia a cada 300 segundos para buscar a lista de itens que queremos permitir.

Ele armazena o cache da resposta no argumento /file, portanto neste exemplo /tmp/vanity_urls

Portanto, se você visitar a instância do AEM no URI, verá o que ela encontra:

É uma lista muito simples.

Substituir regras como regras personalizadas

Por que mencionaríamos o uso de regras de regravação em vez do mecanismo padrão integrado ao AEM, conforme descrito acima?

Explicados de forma simples, problemas de namespace, desempenho e lógica de nível superior que podem ser melhor tratados.

Vamos ver um exemplo da entrada personalizada /aboutus para seu conteúdo /content/we-retail/us/en/about-us.html usando o módulo mod_rewrite do Apache.

RewriteRule /aboutus /content/we-retail/us/en/about-us.html PT,L,NC

Essa regra procurará a personalização /aboutus e buscará o caminho completo do renderizador com o sinalizador PT (Pass Through).

Ele também deixará de processar todas as outras regras do sinalizador L (Last), o que significa que não precisará percorrer uma enorme lista de regras, como a Resolução JCR precisa fazer.

Além de não ter que fazer o proxy da solicitação e esperar que o editor AEM responda a esses dois elementos desse método, ele tem um desempenho muito maior.

Em seguida, a cereja do bolo aqui é o sinalizador NC (Sem distinção entre maiúsculas e minúsculas), o que significa que se você folhear a URL com /Aboutus em vez de /aboutus, ela ainda funcionará e permitirá que a página correta seja buscada.

Para criar uma regra de regravação para fazer isso, você criaria um arquivo de configuração no Dispatcher (exemplo: /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules) e o incluiria no arquivo .vhost que lida com o domínio que precisa dessas URLs personalizadas para serem aplicadas.

Este é um trecho de código de exemplo da inclusão dentro de:

/etc/httpd/conf.d/enabled_vhosts/we-retail.vhost
 VirtualHost *:80    ServerName    weretail.com    ServerAlias

www.weretail.com        ........ SNIP ........     IfModule mod_rewrite.c

   ReWriteEngine    on       LogLevel warn rewrite:info

Include /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules      / IfModule
   ........ SNIP ......../VirtualHost

Qual método e onde usá-lo?

A. Usar o AEM para controlar entradas personalizadas tem os seguintes benefícios:

B. Usar mod_rewrite para controlar entradas personalizadas tem os seguintes benefícios:

C. Use ambos os métodos, mas aqui estão os conselhos e critérios que devem ser usados quando:

Observação: se quiser usar o recurso personalizado AEM e evitar o namespace, você pode criar uma convenção de nomenclatura. Usando URLs personalizados aninhados como /brand1/aboutus, brand2/aboutus, brand3/aboutus