Utilização do Dispatcher com vários domínios using-dispatcher-with-multiple-domains

Use o Dispatcher para processar solicitações de página em vários domínios da Web, enquanto oferece suporte às seguintes condições:

Por exemplo, uma empresa publica sites para duas de suas marcas: marca A e marca B. O conteúdo das páginas dos sites é criado no AEM e armazenado no mesmo espaço de trabalho do repositório:

/
| - content
   | - sitea
       | - content nodes
   | - siteb
       | - content nodes

As páginas para a BrandA.com são armazenadas abaixo de /content/sitea. As solicitações do cliente para o URL https://BrandA.com/en.html são retornadas à página renderizada para o nó /content/sitea/en. Da mesma forma, as páginas para a BrandB.com são armazenadas abaixo de /content/siteb.

Ao usar o Dispatcher para armazenar o conteúdo em cache, devem ser feitas associações entre o URL da página na solicitação HTTP do cliente, o caminho do arquivo correspondente no cache e o caminho do arquivo correspondente no repositório.

Solicitações do cliente

Quando os clientes enviam solicitações HTTP para o servidor Web, o URL da página solicitada deve ser resolvido para o conteúdo no cache do Dispatcher e, por fim, para o conteúdo no repositório.

Invalidação de cache

Quando os agentes de replicação de limpeza solicitam que o Dispatcher invalide os arquivos em cache, o caminho do conteúdo no repositório deve resolver para o conteúdo no cache.

Para usar o Dispatcher com vários domínios, você precisa configurar o AEM, o Dispatcher e o servidor Web. Esta página descreve soluções gerais que se aplicam à maioria dos ambientes. Devido à complexidade de algumas topologias do AEM, sua solução pode exigir mais configurações personalizadas para resolver problemas específicos. É provável que você precise adaptar os exemplos para atender às políticas existentes de infraestrutura e gerenciamento de TI.

Mapeamento de URL url-mapping

Para permitir que URLs de domínio e caminhos de conteúdo sejam resolvidos em arquivos em cache, em algum momento do processo um caminho de arquivo ou URL de página deve ser traduzido. São fornecidas descrições das seguintes estratégias comuns, em que as traduções de caminho ou URL ocorrem em diferentes pontos do processo:

No geral, é desejável usar URLs curtos para páginas da Web. Normalmente, os URLs de página espelham a estrutura das pastas do repositório que contêm o conteúdo da Web. No entanto, os URLs não revelam os nós de repositório mais importantes, como /content. O cliente não está necessariamente ciente da estrutura do repositório do AEM.

Requisitos gerais general-requirements

Seu ambiente deve implementar as seguintes configurações para dar suporte ao Dispatcher que trabalha com vários domínios:

Ambiente para os exemplos fornecidos environment-for-the-provided-examples

As soluções de exemplo fornecidas se aplicam a um ambiente com as seguintes características:

  | - /content
    | - sitea
  |    | - content nodes
    | - siteb
       | - content nodes

Raiz do documento do servidor Web

  | - /usr
    | - lib
      | - apache
        | - httpd-2.4.3
          | - htdocs
            | - content
              | - sitea
                 | - content nodes
              | - siteb
                 | - content nodes

O AEM reescreve URLs de entrada aem-rewrites-incoming-urls

O mapeamento Sling para resolução de recursos permite associar URLs recebidos a caminhos de conteúdo do AEM. Crie mapeamentos na instância de publicação do AEM para que as solicitações de renderização do Dispatcher resolvam para o conteúdo correto no repositório.

As solicitações do Dispatcher para renderização de página identificam a página usando o URL transmitido pelo servidor Web. Quando o URL inclui um nome de domínio, os mapeamentos Sling resolvem o URL para o conteúdo. O gráfico a seguir ilustra um mapeamento do URL branda.com/en.html para o nó /content/sitea/en.

O cache do Dispatcher espelha a estrutura do nó do repositório. Portanto, mediante ativações de página, as solicitações resultantes para invalidar a página em cache não exigem URL ou traduções de caminho.

Definição de hosts virtuais no servidor Web define-virtual-hosts-on-the-web-server

Defina hosts virtuais no servidor Web para que uma raiz de documento diferente possa ser atribuída a cada domínio da Web:

O arquivo de exemplo httpd.conf a seguir configura dois domínios virtuais para um servidor Web Apache:

Com essa configuração, o servidor Web executa as seguintes ações quando recebe uma solicitação para https://branda.com/en/products.html:

httpd.conf httpd-conf

# load the Dispatcher module
LoadModule dispatcher_module modules/mod_dispatcher.so
# configure the Dispatcher module
<IfModule disp_apache2.c>
 DispatcherConfig conf/dispatcher.any
 DispatcherLog    logs/dispatcher.log
 DispatcherLogLevel 3
 DispatcherNoServerHeader 0
 DispatcherDeclineRoot 0
 DispatcherUseProcessedURL 0
 DispatcherPassError 0
</IfModule>

# Define virtual host for brandA.com
<VirtualHost *:80>
  ServerName branda.com
  DocumentRoot /usr/lib/apache/httpd-2.4.3/htdocs/content/sitea
   <Directory /usr/lib/apache/httpd-2.4.3/htdocs/content/sitea>
     <IfModule disp_apache2.c>
       SetHandler dispatcher-handler
       ModMimeUsePathInfo On
     </IfModule>
     Options FollowSymLinks
     AllowOverride None
   </Directory>
</VirtualHost>

# define virtual host for brandB.com
<VirtualHost *:80>
  ServerName brandB.com
  DocumentRoot /usr/lib/apache/httpd-2.4.3/htdocs/content/siteb
   <Directory /usr/lib/apache/httpd-2.4.3/htdocs/content/siteb>
     <IfModule disp_apache2.c>
       SetHandler dispatcher-handler
       ModMimeUsePathInfo On
     </IfModule>
     Options FollowSymLinks
     AllowOverride None
   </Directory>
</VirtualHost>

# document root for web server
DocumentRoot "/usr/lib/apache/httpd-2.4.3/htdocs"

Observe que os hosts virtuais herdam o valor da propriedade DispatcherConfig que está configurada na seção do servidor principal. Os hosts virtuais podem incluir sua própria propriedade DispatcherConfig para substituir a configuração do servidor principal.

Configuração do Dispatcher para lidar com vários domínios configure-dispatcher-to-handle-multiple-domains

Para oferecer suporte a URLs que incluem nomes de domínio e seus hosts virtuais correspondentes, defina os seguintes farms do Dispatcher:

Criação de farms do Dispatcher para hosts virtuais

Os farms para hosts virtuais devem ter as seguintes configurações para que os URLs nas solicitações HTTP do cliente sejam resolvidos para os arquivos corretos no cache do Dispatcher:

Além disso, a instância de publicação do AEM deve ser designada como renderização para o host virtual. Configure outras propriedades do farm, conforme necessário. O código a seguir é uma configuração de farm abreviada para o domínio branda.com:

/farm_sitea  {
    ...
    /virtualhosts { "branda.com" }
    /renders {
      /rend01  { /hostname "127.0.0.1"  /port "4503" }
    }
    /filter {
      /0001 { /type "deny"  /glob "*" }
      /0023 { /type "allow" /glob "*/en*" }
      ...
     }
    /cache {
      /docroot "/usr/lib/apache/httpd-2.4.3/htdocs/content/sitea"
      ...
   }
   ...
}

Criar um farm do Dispatcher para invalidação de cache

Um farm do Dispatcher é necessário para manipular solicitações para invalidar arquivos em cache. Esse farm deve ser capaz de acessar arquivos .stat nos diretórios docroot de cada host virtual.

As seguintes configurações de propriedade permitem que o Dispatcher resolva arquivos no repositório de conteúdo do AEM a partir de arquivos no cache:

A propriedade /statfilesleveldeve ser alta o suficiente para que os arquivos .stat sejam criados no diretório raiz de cada host virtual. Essa propriedade permite que o cache de cada domínio seja invalidado separadamente. Para a configuração do exemplo, um valor /statfileslevel de 2 cria arquivos .stat no diretório *docroot*/content/sitea e no diretório *docroot*/content/siteb.

Além disso, a instância de publicação deve ser designada como renderização para o host virtual. Configure outras propriedades do farm, conforme necessário. O código a seguir é uma configuração abreviada para o farm usado para invalidar o cache:

/farm_flush {
    ...
    /virtualhosts   { "invalidation_only" }
    /renders  {
      /rend01  { /hostname "127.0.0.1" /port "4503" }
    }
    /filter   {
      /0001 { /type "deny"  /glob "*" }
      /0023 { /type "allow" /glob "*/content*" }
      ...
      }
    /cache  {
       /docroot "/usr/lib/apache/httpd-2.4.3/htdocs"
       /statfileslevel "2"
       ...
   }
   ...
}

Ao iniciar o servidor Web, o log do Dispatcher (no modo de depuração) indica a inicialização de todos os farms:

Dispatcher initializing (build 4.1.2)
[Fri Nov 02 16:27:18 2012] [D] [24974(140006182991616)] farms[farm_sitea].cache.docroot = /usr/lib/apache/httpd-2.4.3/htdocs/content/sitea
[Fri Nov 02 16:27:18 2012] [D] [24974(140006182991616)] farms[farm_siteb].cache.docroot = /usr/lib/apache/httpd-2.4.3/htdocs/content/siteb
[Fri Nov 02 16:27:18 2012] [D] [24974(140006182991616)] farms[farm_flush].cache.docroot = /usr/lib/apache/httpd-2.4.3/htdocs
[Fri Nov 02 16:27:18 2012] [I] [24974(140006182991616)] Dispatcher initialized (build 4.1.2)

Configuração do mapeamento Sling para resolução de recursos configure-sling-mapping-for-resource-resolution

Use o mapeamento Sling para resolução de recursos, de modo que os URLs baseados em domínio resolvam para o conteúdo na instância de publicação do AEM. O mapeamento de recursos traduz os URLs recebidos do Dispatcher (originalmente de solicitações HTTP do cliente) para nós de conteúdo.

Para saber mais sobre o mapeamento de recursos Sling, consulte Mapeamentos para resolução de recursos, na documentação do Sling.

Normalmente, os mapeamentos são necessários para os seguintes recursos, embora possam ser necessários mapeamentos adicionais:

Depois de criar o mapeamento para a página de conteúdo, para descobrir os mapeamentos necessários adicionais, use um navegador da Web para abrir uma página no servidor Web. No arquivo error.log da instância de publicação, localize mensagens sobre recursos que não foram encontrados. A seguinte mensagem de exemplo indica que é necessário um mapeamento para /etc/clientlibs:

01.11.2012 15:59:24.601 *INFO* [10.36.34.243 [1351799964599] GET /etc/clientlibs/foundation/jquery.js HTTP/1.1] org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Resource /content/sitea/etc/clientlibs/foundation/jquery.js not found

Exemplo de nós de mapeamento de recursos

A tabela a seguir lista os nós que implementam o mapeamento de recursos para o domínio branda.com. Os nós semelhantes são criados para o domínio brandb.com, como /etc/map/http/brandb.com. Em todos os casos, os mapeamentos são necessários quando as referências no HTML da página não são resolvidas corretamente no contexto do Sling.

Configuração do agente de replicação de limpeza do Dispatcher configuring-the-dispatcher-flush-replication-agent

O agente de replicação de limpeza do Dispatcher na instância de publicação do AEM deve enviar solicitações de invalidação para o farm correto do Dispatcher. Para direcionar um farm, use a propriedade URI do agente de replicação de limpeza do Dispatcher (na guia Transporte). Inclua o valor da propriedade /virtualhost para o farm do Dispatcher configurado para invalidar o cache:

https://*webserver_name*:*port*/*virtual_host*/dispatcher/invalidate.cache

Por exemplo, para usar o farm farm_flush do exemplo anterior, o URI é https://localhost:80/invalidation_only/dispatcher/invalidate.cache.

O servidor Web reescreve URLs de entrada the-web-server-rewrites-incoming-urls

Use o recurso interno de reescrita de URL do seu servidor Web para traduzir URLs baseados em domínio para caminhos de arquivo no cache do Dispatcher. Por exemplo, as solicitações do cliente para a página https://brandA.com/en.html são traduzidas para o arquivo content/sitea/en.html na raiz do documento do servidor Web.

O cache do Dispatcher espelha a estrutura do nó do repositório. Portanto, mediante ativações de página, as solicitações resultantes para invalidar a página em cache não exigem URL ou traduções de caminho.

Definição de hosts virtuais e reescrita de regras no servidor Web define-virtual-hosts-and-rewrite-rules-on-the-web-server

Configure os seguintes aspectos no servidor Web:

O seguinte exemplo de arquivo httpd.conf configura dois hosts virtuais para um servidor Web Apache:

Por exemplo, o servidor Web executa as seguintes ações quando recebe uma solicitação com o URL https://brandA.com/en/products.html:

httpd.conf httpd-conf-1

# load the Dispatcher module
LoadModule dispatcher_module modules/mod_dispatcher.so
# configure the Dispatcher module
<IfModule disp_apache2.c>
 DispatcherConfig conf/dispatcher.any
 DispatcherLog    logs/dispatcher.log
 DispatcherLogLevel 3
 DispatcherNoServerHeader 0
 DispatcherDeclineRoot 0
 DispatcherUseProcessedURL 1
 DispatcherPassError 0
</IfModule>

# Define virtual host for brandA.com
<VirtualHost *:80>
  ServerName branda.com
  DocumentRoot /usr/lib/apache/httpd-2.4.3/htdocs/content/sitea
  RewriteEngine  on
  RewriteRule    ^/(.*)\.html$  /content/sitea/$1.html [PT]
   <Directory /usr/lib/apache/httpd-2.4.3/htdocs/content/sitea>
     <IfModule disp_apache2.c>
       SetHandler dispatcher-handler
       ModMimeUsePathInfo On
     </IfModule>
     Options FollowSymLinks
     AllowOverride None
   </Directory>
</VirtualHost>

# define virtual host for brandB.com
<VirtualHost *:80>
  ServerName brandB.com
  DocumentRoot /usr/lib/apache/httpd-2.4.3/htdocs/content/siteb
  RewriteEngine  on
  RewriteRule    ^/(.*)\.html$  /content/siteb/$1.html [PT]
   <Directory /usr/lib/apache/httpd-2.4.3/htdocs/content/siteb>
     <IfModule disp_apache2.c>
       SetHandler dispatcher-handler
       ModMimeUsePathInfo On
     </IfModule>
     Options FollowSymLinks
     AllowOverride None
   </Directory>
</VirtualHost>

# document root for web server
DocumentRoot "/usr/lib/apache/httpd-2.4.3/htdocs"

Configuração de um farm do Dispatcher configure-a-dispatcher-farm

Quando o servidor Web reescreve URLs, o Dispatcher requer um único farm definido de acordo com a Configuração do Dispatcher. As seguintes configurações são necessárias para suportar hosts virtuais do servidor Web e regras de renomeação de URL:

O exemplo de arquivo de configuração a seguir é baseado no arquivo de exemplo dispatcher.any que está instalado com o Dispatcher. As seguintes alterações são necessárias para suportar as configurações do servidor Web do arquivo httpd.conf anterior:

Como de costume, a raiz do documento do cache é a mesma raiz do documento do servidor Web (linha 40): /usr/lib/apache/httpd-2.4.3/htdocs

dispatcher.any dispatcher-any

/name "testDispatcher"
/farms
  {
  /dispfarm0
    {
    /clientheaders
      {
      "*"
      }
    /virtualhosts
      {
      "brandA.com" "brandB.com"
      }
    /renders
      {
      /rend01    {  /hostname "127.0.0.1"   /port "4503"  }
      }
    /filter
      {
      /0001 { /type "deny"  /glob "*" }
      /0023 { /type "allow" /glob "*/content*" }  # disable this rule to allow mapped content only
      /0041 { /type "allow" /glob "* *.css *"   }  # enable css
      /0042 { /type "allow" /glob "* *.gif *"   }  # enable gifs
      /0043 { /type "allow" /glob "* *.ico *"   }  # enable icos
      /0044 { /type "allow" /glob "* *.js *"    }  # enable javascript
      /0045 { /type "allow" /glob "* *.png *"   }  # enable png
      /0046 { /type "allow" /glob "* *.swf *"   }  # enable flash
      /0061 { /type "allow" /glob "POST /content/[.]*.form.html" }  # allow POSTs to form selectors under content
      /0062 { /type "allow" /glob "* /libs/cq/personalization/*"  }  # enable personalization
      /0081 { /type "deny"  /glob "GET *.infinity.json*" }
      /0082 { /type "deny"  /glob "GET *.tidy.json*"     }
      /0083 { /type "deny"  /glob "GET *.sysview.xml*"   }
      /0084 { /type "deny"  /glob "GET *.docview.json*"  }
      /0085 { /type "deny"  /glob "GET *.docview.xml*"  }
      /0086 { /type "deny"  /glob "GET *.*[0-9].json*" }
      /0090 { /type "deny"  /glob "* *.query.json*" }
      }
    /cache
      {
      /docroot "/usr/lib/apache/httpd-2.4.3/htdocs"
      /statfileslevel "2"
      /allowAuthorized "0"
      /rules
        {
        /0000  { /glob "*"     /type "allow"  }
        }
      /invalidate
        {
        /0000  {   /glob "*" /type "deny"  }
        /0001 {  /glob "*.html" /type "allow"  }
        }
      /allowedClients
        {
        }
      }
    /statistics
      {
      /categories
        {
        /html  { /glob "*.html" }
        /others  {  /glob "*"  }
        }
      }
    }
  }

Reescrita de links para arquivos que não são HTML rewriting-links-to-non-html-files

Para reescrever referências a arquivos com extensões diferentes de .html ou .htm, crie um componente de transformador de reescrita do Sling e adicione-o ao pipeline de reescrita padrão.

Reescreva referências quando os caminhos de recursos não resolverem corretamente no contexto do servidor Web. Por exemplo, um transformador é necessário quando os componentes geradores de imagem criam links como /content/sitea/en/products.navimage.png. O componente de navegação superior de Como criar um site completo cria esses links.

O reescritor Sling é um módulo que pós-processa a saída do Sling. As implementações de pipeline SAX da reescrita consistem em um gerador, um ou mais transformadores e um serializador:

Pipeline de reescrita padrão do AEM the-aem-default-rewriter-pipeline

O AEM usa uma reescrita de pipeline padrão que processa documentos do tipo text/html:

O nó /libs/cq/config/rewriter/default define o pipeline.

Criação de um transformador creating-a-transformer

Execute as seguintes tarefas para criar um componente de transformador e usá-lo em um pipeline:

Os exemplos a seguir implementam um transformador que reescreve referências a arquivos de imagem.

Os exemplos não são robustos e não devem ser usados em um ambiente de produção.

Exemplo de implementação de TransformerFactory example-transformerfactory-implementation

package com.adobe.example;

import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Service;
import org.apache.felix.scr.annotations.Property;

import org.apache.sling.rewriter.Transformer;
import org.apache.sling.rewriter.TransformerFactory;

@Component
@Service
public class MyRewriterTransformerFactory implements TransformerFactory {
    /* Define the alias */
    @Property(value="mytransformer")
    static final String PIPELINE_TYPE ="pipeline.type";

    public Transformer createTransformer() {

        return new MyRewriterTransformer ();
    }
}

Exemplo de implementação do transformador example-transformer-implementation

package com.adobe.example;

import java.io.IOException;

import org.apache.cocoon.xml.sax.AbstractSAXPipe;

import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.rewriter.ProcessingComponentConfiguration;
import org.apache.sling.rewriter.ProcessingContext;
import org.apache.sling.rewriter.Transformer;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.AttributesImpl;

import javax.servlet.http.HttpServletRequest;

public class MyRewriterTransformer extends AbstractSAXPipe implements Transformer {

 private static final Logger log = LoggerFactory.getLogger(MyRewriterTransformer.class);
 private SlingHttpServletRequest httpRequest;
 /* The element and attribute to act on  */
 private static final String ATT_NAME = new String("src");
 private static final String EL_NAME = new String("img");

 public MyRewriterTransformer () {
 }
 public void dispose() {
 }
 public void init(ProcessingContext context, ProcessingComponentConfiguration config) throws IOException {
  this.httpRequest = context.getRequest();
  log.debug("Transforming request {}.", httpRequest.getRequestURI());
 }
 @Override
 public void startElement (String nsUri, String localname, String qname, Attributes atts) throws SAXException {
  /* copy the element attributes */
  AttributesImpl linkAtts = new AttributesImpl(atts);
  /* Only interested in EL_NAME elements */
  if(EL_NAME.equalsIgnoreCase(localname)){

   /* iterate through the attributes of the element and act only on ATT_NAME attributes */
   for (int i=0; i < linkAtts.getLength(); i++) {
    if (ATT_NAME.equalsIgnoreCase(linkAtts.getLocalName(i))) {
     String path_in_link = linkAtts.getValue(i);

     /* use the resource resolver of the http request to reverse-resolve the path  */
     String mappedPath = httpRequest.getResourceResolver().map(httpRequest, path_in_link);

     log.info("Tranformed {} to {}.", path_in_link,mappedPath);

     /* update the attribute value */
     linkAtts.setValue(i,mappedPath);
    }
   }

  }
        /* return updated attributes to super and continue with the transformer chain */
 super.startElement(nsUri, localname, qname, linkAtts);
 }
}

Adicionar o transformador a um pipeline de reescrita adding-the-transformer-to-a-rewriter-pipeline

Crie um nó JCR que define um pipeline que usa o seu transformador. A definição de nó a seguir cria um pipeline que processa arquivos de texto/html. O gerador e o analisador padrão do AEM para HTML são usados.

Nó de configuração do reescritor - representação XML rewriter-configuration-node-xml-representation

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:nt="https://www.jcp.org/jcr/nt/1.0"
    jcr:primaryType="nt:unstructured"
    contentTypes="[text/html]"
    enabled="{Boolean}true"
    generatorType="htmlparser"
    order="5"
    serializerType="htmlwriter"
    transformerTypes="[mytransformer]">
</jcr:root>

O gráfico a seguir mostra a representação CRXDE Lite do nó: