URLs personalizados do Dispatcher

Este documento ajudará você a entender como o AEM lida com urls personalizados e algumas técnicas adicionais usando regras de regravação para mapear o conteúdo mais próximo da borda do delivery

🏠Índice

🔙Fluxo Anterior do Dispatcher

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:/aboutus apontou para /content/we-retail/us/en/about-us.html

Os AEM Author têm a opção de definir as 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. Essa ação 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.

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 do usuário de toque:

Menu suspenso de diálogo para a interface de usuário de criação do AEM na tela do editor do site

página de diálogo de propriedades da página do aem

Localizador de conteúdo clássico:

Propriedades da página de sidekick clássica do AEM siteadmin

Caixa de diálogo Propriedades da página da interface de usuário clássica

Observação:

Ela é muito vulnerável a problemas de espaço.

Entradas personalizadas são globais para todas as páginas, esta é apenas uma das falhas que você deve planejar para soluções alternativas que explicaremos mais tarde.

Resolução/mapeamento de recursos

Cada entrada personalizada é uma entrada de mapa de sling para um redirecionamento interno.

Esses mapas são visíveis ao visitar o console Felix de instâncias do AEM (/system/console/jcrresolver).

Esta é uma imagem de uma entrada de mapa criada por uma entrada personalizada:

captura de tela do console de uma entrada personalizada nas regras de resolução de recursos

No exemplo acima, quando solicitamos à instância do 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.

https://experience.adobe.com/#/downloads/content/software-distribution/en/aem.html?package=/content/software-distribution/en/details.html/content/dam/aem/public/adobe/packages/granite/vanityurls-components

O Dispatcher tem uma seção de configuração no 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 do AEM que ele envia a cada 300 segundos para buscar a lista de itens que queremos permitir.

Ele armazena seu cache de 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:

captura de tela do conteúdo renderizado em /libs/granite/dispatcher/content/vanityUrls.html

É literalmente uma lista, super 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, como 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 /about a 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 de sinalizador L (Last), o que significa que não terá que atravessar uma enorme lista de regras como a Resolução JCR tem que 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 um cliente acessar o URI com /AboutUs em vez de /aboutus, ele 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 (por exemplo: /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules) e o incluiria no arquivo .vhost que lida com o domínio que precisa dos URLs personalizados para serem aplicados.

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>

Que método e onde

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

  • Os autores podem criá-los dinamicamente
  • Eles vivem com o conteúdo e podem ser empacotados com o conteúdo

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

  • Solução de conteúdo mais rápida
  • Mais próximo da borda das solicitações de conteúdo do usuário final
  • Mais extensibilidade e opções para controlar como o conteúdo é mapeado em outras condições
  • Pode não diferenciar maiúsculas de minúsculas

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

  • Se a personalização for temporária e tiver níveis baixos de tráfego planejado, use o recurso integrado do AEM
  • Se a personalização for um endpoint básico que não muda com frequência e tem uso frequente, use uma regra mod_rewrite
  • Se o namespace personalizado (por exemplo: /aboutus) precisa ser reutilizado para muitas marcas na mesma instância do AEM e depois usar as regras de regravação.
Observação:

Se você quiser usar o recurso personalizado do AEM e evitar o namespace, é possível criar uma convenção de nomenclatura. Usando urls personalizadas aninhadas como /brand1/aboutus, brand2/aboutus, brand3/aboutus.

Próximo ➡ registro comum

Logotipo da Adobe

Fazer logon em sua conta