Configurazione di Dispatcher

Nelle sezioni seguenti viene descritto come configurare vari aspetti del dispatcher.

Supporto per IPv4 e IPv6

Tutti gli elementi di AEM e Dispatcher possono essere installati nelle reti IPv4 e IPv6. Vedere IPV4 e IPV6.

File di configurazione del dispatcher

Per impostazione predefinita, la configurazione del dispatcher è memorizzata nel file di testo dispatcher.any, anche se è possibile modificare il nome e la posizione del file durante l'installazione.

Il file di configurazione contiene una serie di proprietà a valore singolo o multivalore che controllano il comportamento del dispatcher:

• I nomi delle proprietà hanno il prefisso "forward slash /.
• Le proprietà con più valori racchiudono elementi secondari utilizzando le parentesi graffe { }.

Una configurazione di esempio è strutturata come segue:

# name of the dispatcher
/name "internet-server"

# each farm configures a set off (loadbalanced) renders
/farms
 {
  # first farm entry (label is not important, just for your convenience)
   /website
     {  
     /clientheaders
       {
       # List of headers that are passed on
       }
     /virtualhosts
       {
       # List of URLs for this Web site
       }
     /sessionmanagement
       {
       # settings for user authentification
       }
     /renders
       {
       # List of AEM instances that render the documents
       }
     /filter
       {
       # List of filters
       }
     /vanity_urls
       {
       # List of vanity URLs
       }
     /cache
       {
       # Cache configuration
       /rules
         {
         # List of cachable documents
         }
       /invalidate
         {
         # List of auto-invalidated documents
         }
       }
     /statistics
       {
       /categories
         {
         # The document categories that are used for load balancing estimates
         }
       }
     /stickyConnectionsFor "/myFolder"
     /health_check
       {
       # Page gets contacted when an instance returns a 500
       }
     /retryDelay "1"
     /numberOfRetries "5"
     /unavailablePenalty "1"
     /failover "1"
     }
 }

Potete includere altri file che contribuiscono alla configurazione:

• Se il file di configurazione è grande, potete suddividerlo in diversi file più piccoli (che sono più facili da gestire) e quindi includerli.
• Per includere i file generati automaticamente.

Ad esempio, per includere il file myFarm.any nella configurazione /farm, utilizza il seguente codice:

/farms
  {
  $include "myFarm.any"
  }

Utilizzate l'asterisco (*) come carattere jolly per specificare un intervallo di file da includere.

Ad esempio, se i file da farm_1.any a farm_5.any contengono la configurazione delle farm da uno a cinque, è possibile includerli come segue:

/farms
  {
  $include "farm_*.any"
  }

Utilizzo delle variabili di ambiente

È possibile utilizzare le variabili di ambiente nelle proprietà con valori stringa nel file dispatcher.any anziché codificare i valori. Per includere il valore di una variabile di ambiente, utilizzare il formato ${variable_name}.

Ad esempio, se il file dispatcher.any si trova nella stessa directory della directory della cache, è possibile utilizzare il seguente valore per la proprietà docroot:

/docroot "${PWD}/cache"

Ad esempio, se create una variabile di ambiente denominata PUBLISH_IP che memorizza il nome host dell'istanza di pubblicazione AEM, potete utilizzare la seguente configurazione della proprietà /renders:

/renders {
  /0001 {
    /hostname "${PUBLISH_IP}"
    /port "8443"
  }
}

Denominazione dell'istanza del dispatcher

Utilizzare la proprietà /name per specificare un nome univoco per identificare l'istanza del Dispatcher. La proprietà /name è una proprietà di primo livello nella struttura di configurazione.

Definizione di farm

La proprietà /farms definisce uno o più set di comportamenti del dispatcher, in cui ogni set è associato a siti Web o URL diversi. La proprietà /farms può includere una o più farm:

• Utilizzate un'unica farm quando desiderate che il dispatcher gestisca tutte le pagine Web o i siti Web nello stesso modo.
• Creare più farm quando aree diverse del sito Web o siti Web diversi richiedono un comportamento diverso da quello del dispatcher.

La proprietà /farms è una proprietà di primo livello nella struttura di configurazione. Per definire una farm, aggiungete una proprietà figlio alla proprietà /farms. Utilizzate un nome di proprietà che identifichi in modo univoco la farm all'interno dell'istanza Dispatcher.

La proprietà /farmname ha più valori e contiene altre proprietà che definiscono il comportamento del dispatcher:

• URL delle pagine a cui si applica la farm.
• Uno o più URL del servizio (in genere di AEM istanze di pubblicazione) da utilizzare per il rendering dei documenti.
• Statistiche da utilizzare per il bilanciamento del carico di più renderer di documenti.
• Diversi altri comportamenti, ad esempio quali file memorizzare nella cache e dove.

Il valore può includere qualsiasi carattere alfanumerico (a-z, 0-9). L'esempio seguente mostra la definizione dello scheletro per due farm denominate /daycom e /docsdaycom:

#name of dispatcher
/name "day sites"

#farms section defines a list of farms or sites
/farms
{
   /daycom
   {
       ...
   }
   /docdaycom
   {
      ...
   }
}

Ogni proprietà farm può contenere le seguenti proprietà figlio:

Specificare una pagina predefinita (solo IIS) - /homepage

Specifica delle intestazioni HTTP da passare attraverso

La proprietà /clientheaders definisce un elenco di intestazioni HTTP che il dispatcher trasmette dalla richiesta HTTP client al renderer (istanza AEM).

Per impostazione predefinita, il dispatcher inoltra le intestazioni HTTP standard all'istanza AEM. In alcuni casi, potrebbe essere necessario inoltrare intestazioni aggiuntive o rimuovere intestazioni specifiche:

• Aggiungete intestazioni, ad esempio intestazioni personalizzate, che l’istanza AEM prevede nella richiesta HTTP.
• Rimuovete le intestazioni, ad esempio le intestazioni di autenticazione, rilevanti solo per il server Web.

Se personalizzate il set di intestazioni da scorrere, dovete specificare un elenco completo di intestazioni, incluse quelle normalmente incluse per impostazione predefinita.

Ad esempio, un'istanza del dispatcher che gestisce le richieste di attivazione della pagina per le istanze di pubblicazione richiede l'intestazione PATH nella sezione /clientheaders. L'intestazione PATH consente la comunicazione tra l'agente di replica e il dispatcher.

Di seguito è riportato un esempio di configurazione per /clientheaders:

/clientheaders
  {
  "CSRF-Token"
  "X-Forwarded-Proto"
  "referer"
  "user-agent"
  "authorization"
  "from"
  "content-type"
  "content-length"
  "accept-charset"
  "accept-encoding"
  "accept-language"
  "accept"
  "host"
  "if-match"
  "if-none-match"
  "if-range"
  "if-unmodified-since"
  "max-forwards"
  "proxy-authorization"
  "proxy-connection"
  "range"
  "cookie"
  "cq-action"
  "cq-handle"
  "handle"
  "action"
  "cqstats"
  "depth"
  "translate"
  "expires"
  "date"
  "dav"
  "ms-author-via"
  "if"
  "lock-token"
  "x-expected-entity-length"
  "destination"
  "PATH"
  }

Identificazione host virtuali

La proprietà /virtualhosts definisce un elenco di tutte le combinazioni hostname/URI accettate dal Dispatcher per questa farm. È possibile utilizzare il carattere asterisco (*) come carattere jolly. I valori per la proprietà / virtualhosts utilizzano il formato seguente:

[scheme]host[uri][*]

• scheme: (Facoltativo) https:// oppure https://.
• host: Nome o indirizzo IP del computer host e, se necessario, numero di porta. (Vedere https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23)
• uri: (Facoltativo) Percorso delle risorse.

La seguente configurazione di esempio gestisce le richieste per i domini .com e .ch della mia azienda e per tutti i domini di mySubDivision:

   /virtualhosts
    {
    "www.myCompany.com"
    "www.myCompany.ch"
    "www.mySubDivison.*"
    }

La seguente configurazione gestisce tutte le richieste tutte:

   /virtualhosts
    {
    "*"
    }

Risoluzione dell'host virtuale

Quando il dispatcher riceve una richiesta HTTP o HTTPS, trova il valore host virtuale che meglio corrisponde alle intestazioni host, uri e scheme della richiesta. Il dispatcher valuta i valori delle proprietà virtualhosts nel seguente ordine:

• Il dispatcher inizia dalla farm più bassa e procede verso l’alto nel file dispatcher.any.
• Per ogni farm, il dispatcher inizia con il valore superiore nella proprietà virtualhosts e procede verso il basso fino all'elenco dei valori.

Dispatcher trova il valore host virtuale più simile nel modo seguente:

• Viene utilizzato il primo host virtuale rilevato che corrisponde a tutti e tre i host, il scheme e il uri della richiesta.
• Se nessun valore di virtualhosts ha scheme e uri parti che corrispondono sia a scheme che a uri della richiesta, viene utilizzato il primo host virtuale rilevato che corrisponde al host della richiesta.
• Se nessun valore virtualhosts ha una parte host che corrisponde all'host della richiesta, viene utilizzato l'host virtuale superiore della farm superiore.

Pertanto, è necessario posizionare l'host virtuale predefinito nella parte superiore della proprietà virtualhosts nella farm superiore del file dispatcher.any.

Esempio di risoluzione host virtuale

L'esempio seguente rappresenta uno snippet da un file dispatcher.any che definisce due farm Dispatcher e ogni farm definisce una proprietà virtualhosts.

/farms
  {
  /myProducts
    {
    /virtualhosts
      {
      "www.mycompany.com"
      }
    /renders
      {
      /hostname "server1.myCompany.com"
      /port "80"
      }
    }
  /myCompany
    {
    /virtualhosts
      {
      "www.mycompany.com/products/*"
      }
    /renders
      {
      /hostname "server2.myCompany.com"
      /port "80"
      }
    }
  }

Utilizzando questo esempio, la tabella seguente mostra gli host virtuali risolti per le richieste HTTP indicate:

Abilitazione di sessioni protette - /session management

Create una sessione protetta per l'accesso alla farm di rendering in modo che gli utenti debbano accedere a qualsiasi pagina della farm. Dopo l'accesso, gli utenti possono accedere alle pagine della farm. Per informazioni sull'utilizzo di questa funzione con i CUG, vedere Creazione di un gruppo di utenti chiuso. Inoltre, vedere il Dispatcher Security Checklist prima di iniziare a vivere.

La proprietà /sessionmanagement è una sottoproprietà di /farms.

/ sessionmanagementhas diversi sottoparametri:

/directory (obbligatorio)

La directory in cui sono memorizzate le informazioni della sessione. Se la directory non esiste, viene creata.

/sessionmanagement
  {
  /directory "/usr/local/apache/.sessions"
  }

/encode (facoltativo)

Modalità di codifica delle informazioni sulla sessione. Utilizzate md5 per la cifratura utilizzando l'algoritmo md5 oppure hex per la codifica esadecimale. Se crittografate i dati della sessione, un utente con accesso al file system non sarà in grado di leggere il contenuto della sessione. Il valore predefinito è md5.

/header (facoltativo)

Nome dell’intestazione HTTP o del cookie in cui vengono memorizzate le informazioni di autorizzazione. Se archiviate le informazioni nell'intestazione http, utilizzate HTTP:<header-name>. Per memorizzare le informazioni in un cookie, utilizzare Cookie:<header-name>. Se non si specifica un valore HTTP:authorization viene utilizzato.

/timeout (facoltativo)

Il numero di secondi fino al timeout della sessione dopo l’ultimo utilizzo. Se non viene specificato "800", la sessione si interrompe poco più di 13 minuti dopo l’ultima richiesta dell’utente.

Esempio di configurazione:

/sessionmanagement
  {
  /directory "/usr/local/apache/.sessions"
  /encode "md5"
  /header "HTTP:authorization"
  /timeout "800"
  }

Definizione dei renderer di pagina

La proprietà /renders definisce l'URL al quale il dispatcher invia le richieste per eseguire il rendering di un documento. L'esempio seguente /renders identifica una singola istanza AEM per il rendering:

/renders
  {
    /myRenderer
      {
      # hostname or IP of the renderer
      /hostname "aem.myCompany.com"
      # port of the renderer
      /port "4503"
      # connection timeout in milliseconds, "0" (default) waits indefinitely
      /timeout "0"
      }
  }

La sezione di esempio /renders seguente identifica un'istanza AEM eseguita sullo stesso computer del dispatcher:

/renders
  {
    /myRenderer
     {
     /hostname "127.0.0.1"
     /port "4503"
     }
  }

La sezione di esempio /renders seguente distribuisce le richieste di rendering in modo uniforme tra due istanze AEM:

/renders
  {
    /myFirstRenderer
      {
      /hostname "aem.myCompany.com"
      /port "4503"
      }
    /mySecondRenderer
      {
      /hostname "127.0.0.1"
      /port "4503"
      }
  }

Opzioni di rendering

/timeout

Specifica il timeout di connessione per l’accesso all’istanza AEM, in millisecondi. Il valore predefinito è "0", che determina un’attesa indefinita del dispatcher.

/receiveTimeout

Specifica il tempo in millisecondi che una risposta può richiedere. Il valore predefinito è "600000", che causa l’attesa del dispatcher di 10 minuti. L’impostazione "0" elimina completamente il timeout.

Se viene raggiunto il timeout durante l'analisi delle intestazioni di risposta, viene restituito uno stato HTTP 504 (gateway non valido). Se il timeout viene raggiunto durante la lettura del corpo della risposta, il dispatcher restituirà la risposta incompleta al client, ma eliminerà tutti i file della cache eventualmente scritti.

/ipv4

Specifica se il dispatcher utilizza la funzione getaddrinfo (per IPv6) o la funzione gethostbyname (per IPv4) per ottenere l'indirizzo IP del rendering. Il valore 0 determina l'utilizzo di getaddrinfo. Un valore di 1 causa l'utilizzo di gethostbyname. Il valore predefinito è 0.

La funzione getaddrinfo restituisce un elenco di indirizzi IP. Dispatcher esegue un'iterazione dell'elenco di indirizzi finché non stabilisce una connessione TCP/IP. Di conseguenza, la proprietà ipv4 è importante quando il nome host di rendering è associato a più indirizzi IP e l'host, in risposta alla funzione getaddrinfo, restituisce un elenco di indirizzi IP sempre nello stesso ordine. In questa situazione, è necessario utilizzare la funzione gethostbyname in modo che l'indirizzo IP con cui il Dispatcher si connette sia casuale.

il sistema ELB (Elastic Load Balancing) di Amazon è un servizio che risponde a getaddrinfo con un elenco potenzialmente uguale di indirizzi IP.

/secure

Se la proprietà /secure ha un valore di "1" Dispatcher utilizza HTTPS per comunicare con l’istanza AEM. Per ulteriori dettagli, vedere anche Configurazione del dispatcher per l’utilizzo di SSL.

/always-resolve

Con la versione del dispatcher 4.1.6, è possibile configurare la proprietà /always-resolve come segue:

• Se impostato su "1", il nome host verrà risolto su ogni richiesta (il dispatcher non memorizzerà mai nella cache alcun indirizzo IP). Potrebbe verificarsi un leggero impatto sulle prestazioni a causa della chiamata aggiuntiva necessaria per ottenere le informazioni sull’host per ogni richiesta.
• Se la proprietà non è impostata, l'indirizzo IP verrà memorizzato nella cache per impostazione predefinita.

Questa proprietà può essere utilizzata anche in caso di problemi di risoluzione IP dinamica, come illustrato nell'esempio seguente:

/renders {
  /0001 {
     /hostname "host-name-here"
     /port "4502"
     /ipv4 "1"
     /always-resolve "1"
     }
  }

Configurazione dell'accesso al contenuto

Utilizzate la sezione /filter per specificare le richieste HTTP accettate da Dispatcher. Tutte le altre richieste vengono inviate al server Web con un codice di errore 404 (pagina non trovata). Se non esiste alcuna sezione /filter, tutte le richieste vengono accettate.

Nota: le richieste per il file di stato vengono sempre rifiutate.

La sezione /filter è composta da una serie di regole che negano o consentono l'accesso al contenuto in base ai pattern contenuti nella parte della riga della richiesta HTTP. È consigliabile utilizzare una strategia di elenco consentiti per la sezione /filter:

• In primo luogo, negare l'accesso a tutto.
• Consentire l'accesso al contenuto in base alle esigenze.

Definizione di un filtro

Ogni elemento della sezione /filter include un tipo e un pattern associati a un elemento specifico della riga della richiesta o all'intera riga della richiesta. Ogni filtro può contenere i seguenti elementi:

• Tipo: Indica /type se consentire o negare l'accesso alle richieste che corrispondono al pattern. Il valore può essere allow o deny.

• Elemento della linea di richiesta: Includi /method, /urlo /query /protocol e un pattern per filtrare le richieste in base a queste parti specifiche della parte della riga di richiesta della richiesta HTTP. Il filtraggio sugli elementi della riga della richiesta (anziché sull’intera riga della richiesta) è il metodo di filtro preferito.

• Elementi avanzati della linea di richiesta: A partire da Dispatcher 4.2.0, sono disponibili quattro nuovi elementi filtro. Questi nuovi elementi sono /path, /selectors, /extension e /suffix rispettivamente. Includete uno o più di questi elementi per controllare ulteriormente i pattern URL.

• Proprietà elemento: La /glob proprietà viene utilizzata per corrispondere all'intera riga di richiesta della richiesta HTTP.

Parte della riga di richiesta delle richieste HTTP

HTTP/1.1 definisce request-line come segue:

Method Request-URI HTTP-Version<CRLF>

I caratteri <CRLF> rappresentano un ritorno a capo seguito da un avanzamento riga. L'esempio seguente è la riga di richiesta ricevuta quando un cliente richiede la pagina inglese USA del sito WKND:

GET /content/wknd/us/en.html HTTP.1.1<CRLF>

I pattern devono tenere conto degli spazi nella riga di richiesta e dei caratteri <CRLF>.

virgolette doppie e virgolette singole

Quando create le regole del filtro, utilizzate le doppie virgolette "pattern" per i pattern semplici. Se si utilizza Dispatcher 4.2.0 o versione successiva e il pattern include un’espressione regolare, è necessario racchiudere il pattern regex '(pattern1|pattern2)' tra virgolette singole.

Espressioni regolari

Nelle versioni di Dispatcher successive alla 4.2.0, è possibile includere nei modelli di filtro anche le espressioni regolari POSIX Extended.

Risoluzione dei problemi relativi ai filtri

Se i filtri non si attivano come previsto, abilitare Trace Logging nel dispatcher per vedere quale filtro intercetta la richiesta.

Esempio di filtro: Rifiuta tutto

Nella sezione seguente del filtro di esempio il dispatcher nega le richieste per tutti i file. È necessario negare l'accesso a tutti i file e quindi consentire l'accesso ad aree specifiche.

  /0001  { /glob "*" /type "deny" }

Le richieste a un'area negata in modo esplicito causano la restituzione di un codice di errore 404 (pagina non trovata).

Esempio di filtro: Rifiuta accesso a aree specifiche

I filtri consentono inoltre di negare l’accesso a vari elementi, ad esempio pagine ASP e aree sensibili all’interno di un’istanza di pubblicazione. Il filtro seguente nega l'accesso alle pagine ASP:

/0002  { /type "deny" /url "*.asp"  }

Esempio di filtro: Abilita richieste POST

Il seguente filtro di esempio consente l'invio dei dati del modulo tramite il metodo POST:

/filter {
    /0001  { /glob "*" /type "deny" }
    /0002 { /type "allow" /method "POST" /url "/content/[.]*.form.html" }
}

Esempio di filtro: Consenti accesso alla console Flusso di lavoro

L’esempio seguente mostra un filtro utilizzato per negare l’accesso esterno alla console Flusso di lavoro:

/filter {
    /0001  { /glob "*" /type "deny" }
    /0002  {  /type "allow"  /url "/libs/cq/workflow/content/console*"  }
}

Se l’istanza di pubblicazione utilizza un contesto applicazione Web (ad esempio Pubblica), questo può essere aggiunto anche alla definizione del filtro.

/0003   { /type "deny"  /url "/publish/libs/cq/workflow/content/console/archive*"  }

Se è comunque necessario accedere a singole pagine all'interno dell'area limitata, è possibile consentirne l'accesso. Ad esempio, per consentire l’accesso alla scheda Archivio nella console Flusso di lavoro, aggiungi la sezione seguente:

/0004  { /type "allow"  /url "/libs/cq/workflow/content/console/archive*"   }

Esempio di filtro: Utilizzo di espressioni regolari

Questo filtro abilita le estensioni nelle directory di contenuto non pubblico utilizzando un'espressione regolare, definita qui tra virgolette singole:

/005  {  /type "allow" /extension '(css|gif|ico|js|png|swf|jpe?g)' }

Esempio di filtro: Filtrare elementi aggiuntivi di un URL di richiesta

Di seguito è riportato un esempio di regola che blocca l'acquisizione del contenuto dal percorso /content e dalla relativa struttura ad albero secondaria, utilizzando filtri per percorso, selettori ed estensioni:

/006 {
        /type "deny"
        /path "/content/*"
        /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'
        /extension '(json|xml|html)'
        }

Esempio /filter section

Durante la configurazione del dispatcher, devi limitare il più possibile l'accesso esterno. L'esempio seguente fornisce un accesso minimo per i visitatori esterni:

• /content

• contenuti vari, quali progetti e librerie di clienti; ad esempio:

  • /etc/designs/default*
  • /etc/designs/mydesign*

Dopo aver creato i filtri, verificare l'accesso alla pagina per assicurarsi che l'istanza AEM sia protetta.

La seguente sezione /filter del file dispatcher.any può essere utilizzata come base nel file di configurazione del dispatcher Dispatcher.

Questo esempio è basato sul file di configurazione predefinito fornito con Dispatcher e destinato ad essere utilizzato in un ambiente di produzione. Gli elementi con il prefisso # vengono disattivati (commenti non inseriti). È necessario prestare attenzione nel caso in cui decidiate di attivarli (rimuovendo la # su tale riga) in quanto ciò può avere un impatto sulla sicurezza.

È necessario negare l'accesso a tutto, quindi consentire l'accesso a elementi specifici (limitati):

  /filter
      {
      # Deny everything first and then allow specific entries
      /0001 { /type "deny" /glob "*" }

      # Open consoles
#     /0011 { /type "allow" /url "/admin/*"  }  # allow servlet engine admin
#     /0012 { /type "allow" /url "/crx/*"    }  # allow content repository
#     /0013 { /type "allow" /url "/system/*" }  # allow OSGi console

      # Allow non-public content directories
#     /0021 { /type "allow" /url "/apps/*"   }  # allow apps access
#     /0022 { /type "allow" /url "/bin/*"    }
      /0023 { /type "allow" /url "/content*" }  # disable this rule to allow mapped content only

#     /0024 { /type "allow" /url "/libs/*"   }
#     /0025 { /type "deny"  /url "/libs/shindig/proxy*" } # if you enable /libs close access to proxy

#     /0026 { /type "allow" /url "/home/*"   }
#     /0027 { /type "allow" /url "/tmp/*"    }
#     /0028 { /type "allow" /url "/var/*"    }

      # Enable extensions in non-public content directories, using a regular expression
      /0041
        {
        /type "allow"
        /extension '(css|gif|ico|js|png|swf|jpe?g)'
        }

      # Enable features
      /0062 { /type "allow" /url "/libs/cq/personalization/*"  }  # enable personalization

      # Deny content grabbing, on all accessible pages, using regular expressions
      /0081
        {
        /type "deny"
        /selectors '((sys|doc)view|query|[0-9-]+)'
        /extension '(json|xml)'
        }
      # Deny content grabbing for /content and its subtree
      /0082
        {
        /type "deny"
        /path "/content/*"
        /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'
        /extension '(json|xml|html)'
        }

#     /0087 { /type "allow" /method "GET" /extension 'json' "*.1.json" }  # allow one-level json requests
}

Se scegliete di estendere l'accesso, tenete presenti le seguenti raccomandazioni:

• L'accesso esterno a /admin deve essere sempre completamente disattivato se si utilizza CQ versione 5.4 o una versione precedente.

• Prestate attenzione quando consentite l'accesso ai file in /libs. L'accesso dovrebbe essere consentito su base individuale.

• Negare l'accesso alla configurazione di replica in modo che non possa essere visibile:

  • /etc/replication.xml*
  • /etc/replication.infinity.json*

• Rifiuta l'accesso al proxy inverso Google Gadget:

  • /libs/opensocial/proxy*

A seconda dell'installazione, potrebbero essere disponibili risorse aggiuntive in /libs, /apps o in un'altra area. È possibile utilizzare il file access.log come metodo per determinare le risorse a cui si accede esternamente.

Limitazione delle stringhe di query

Dalla versione 4.1.5 del dispatcher, utilizzate la sezione /filter per limitare le stringhe di query. Si consiglia vivamente di consentire in modo esplicito le stringhe di query ed escludere la tolleranza generica attraverso gli elementi del filtro allow.

Una singola voce può avere glob o una combinazione di method, url, query e version, ma non entrambi. L'esempio seguente consente la stringa di query a=* e nega tutte le altre stringhe di query per gli URL che si risolvono nel nodo /etc:

/filter {
 /0001 { /type "deny" /method "POST" /url "/etc/*" }
 /0002 { /type "allow" /method "GET" /url "/etc/*" /query "a=*" }
}

/filter {  
>/0001 { /type "deny" /method “*" /url "/path/*" }  
>/0002 { /type "allow" /method "GET" /url "/path/*" }  
>/0003 { /type “deny" /method "GET" /url "/path/*" /query "*" }  
>/0004 { /type "allow" /method "GET" /url "/path/*" /query "a=*" }  
}  

Verifica della protezione del dispatcher

I filtri del dispatcher devono bloccare l'accesso alle pagine e agli script seguenti su AEM istanze di pubblicazione. Usate un browser Web per tentare di aprire le pagine seguenti come un visitatore del sito e verificare che venga restituito un codice 404. Se si ottiene un altro risultato, regolate i filtri.

Tenere presente che è necessario visualizzare il rendering normale della pagina per /content/add_valid_page.html?debug=layout.

• /admin
• /system/console
• /dav/crx.default
• /crx
• /bin/crxde/logs
• /jcr:system/jcr:versionStorage.json
• /_jcr_system/_jcr_versionStorage.json
• /libs/wcm/core/content/siteadmin.html
• /libs/collab/core/content/admin.html
• /libs/cq/ui/content/dumplibs.html
• /var/linkchecker.html
• /etc/linkchecker.html
• /home/users/a/admin/profile.json
• /home/users/a/admin/profile.xml
• /libs/cq/core/content/login.json
• /content/../libs/foundation/components/text/text.jsp
• /content/.{.}/libs/foundation/components/text/text.jsp
• /apps/sling/config/org.apache.felix.webconsole.internal.servlet.OsgiManager.config/jcr%3acontent/jcr%3adata
• /libs/foundation/components/primary/cq/workflow/components/participants/json.GET.servlet
• /content.pages.json
• /content.languages.json
• /content.blueprint.json
• /content.-1.json
• /content.10.json
• /content.infinity.json
• /content.tidy.json
• /content.tidy.-1.blubber.json
• /content/dam.tidy.-100.json
• /content/content/geometrixx.sitemap.txt
• /content/add_valid_page.query.json?statement=//*
• /content/add_valid_page.qu%65ry.js%6Fn?statement=//*
• /content/add_valid_page.query.json?statement=//*[@transportPassword]/(@transportPassword%20|%20@transportUri%20|%20@transportUser)
• /content/add_valid_path_to_a_page/_jcr_content.json
• /content/add_valid_path_to_a_page/jcr:content.json
• /content/add_valid_path_to_a_page/_jcr_content.feed
• /content/add_valid_path_to_a_page/jcr:content.feed
• /content/add_valid_path_to_a_page/pagename._jcr_content.feed
• /content/add_valid_path_to_a_page/pagename.jcr:content.feed
• /content/add_valid_path_to_a_page/pagename.docview.xml
• /content/add_valid_path_to_a_page/pagename.docview.json
• /content/add_valid_path_to_a_page/pagename.sysview.xml
• /etc.xml
• /content.feed.xml
• /content.rss.xml
• /content.feed.html
• /content/add_valid_page.html?debug=layout
• /projects
• /tagging
• /etc/replication.html
• /etc/cloudservices.html
• /welcome

Emettere il comando seguente in un terminale o in un prompt dei comandi per determinare se l'accesso in scrittura anonimo è abilitato. Non dovresti essere in grado di scrivere dati sul nodo.

curl -X POST "https://anonymous:anonymous@hostname:port/content/usergenerated/mytestnode"

Emettere il seguente comando in un terminale o in un prompt dei comandi per tentare di annullare la validità della cache del Dispatcher e assicurarsi di ricevere una risposta di codice 404:

curl -H "CQ-Handle: /content" -H "CQ-Path: /content" https://yourhostname/dispatcher/invalidate.cache

Abilitazione dell'accesso agli URL personalizzati

Configura il dispatcher per abilitare l’accesso agli URL personalizzati configurati per le pagine AEM.

Quando l’accesso agli URL personalizzati è abilitato, Dispatcher chiama periodicamente un servizio in esecuzione sull’istanza di rendering per ottenere un elenco di URL personalizzati. Il dispatcher memorizza l'elenco in un file locale. Quando una richiesta di pagina viene rifiutata a causa di un filtro nella sezione /filter, Dispatcher consulta l’elenco degli URL personalizzati. Se l’URL negato è presente nell’elenco, il dispatcher consente l’accesso all’URL personalizzato.

Per abilitare l'accesso agli URL personalizzati, aggiungete una sezione /vanity_urls alla sezione /farms, simile all'esempio seguente:

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

La sezione /vanity_urls contiene le proprietà seguenti:

• /url: Percorso del servizio URL personalizzato in esecuzione sull’istanza di rendering. Il valore di questa proprietà deve essere "/libs/granite/dispatcher/content/vanityUrls.html".

• /file: Il percorso del file locale in cui il dispatcher memorizza l’elenco degli URL personalizzati. Verificate che il dispatcher disponga dell'accesso in scrittura a questo file.

• /delay: (Secondi) L'intervallo tra le chiamate al servizio URL personalizzato.

Utilizzate la procedura seguente per abilitare l'accesso agli URL personalizzati.

1. Se il servizio di rendering è un’istanza AEM, installate il pacchetto `com.adobe.granite.dispatcher.vanityurl.content sull’istanza pubblica (vedete la nota precedente).
2. Per ogni URL personalizzato configurato per una pagina AEM o CQ, accertatevi che la configurazione /filter neghi l'URL. Se necessario, aggiungete un filtro che neghi l’URL.
3. Aggiungete la sezione /vanity_urls sotto /farms.
4. Riavviate il server Web Apache.

Inoltro delle richieste di sindacazione - /propagateSyndPost

Le richieste di sindacazione sono in genere destinate solo al Dispatcher, pertanto per impostazione predefinita non vengono inviate al renderer (ad esempio, un'istanza AEM).

Se necessario, impostare la proprietà /propagateSyndPost su "1" per inoltrare le richieste di sindacazione al Dispatcher. Se impostato, accertatevi che le richieste POST non vengano negate nella sezione del filtro.

Configurazione della cache del dispatcher - /cache

La sezione /cache controlla come il dispatcher memorizza nella cache i documenti. Configurate diverse sottoproprietà per implementare le strategie di memorizzazione nella cache:

• /docroot
• /statfile
• /serveStaleOnError
• /allowAuthorized
• /rules
• /statfileslevel
• /invalidate
• /invalidateHandler
• /allowedClients
• /ignoreUrlParams
• /headers
• /mode
• /gracePeriod
• /enableTTL

Esempio di sezione della cache:

/cache
  {
  /docroot "/opt/dispatcher/cache"
  /statfile  "/tmp/dispatcher-website.stat"
  /allowAuthorized "0"

  /rules
    {
    # List of files that are cached
    }

  /invalidate
    {
    # List of files that are auto-invalidated
    }
  }
  

Specifica della directory cache

La proprietà /docroot identifica la directory in cui vengono memorizzati i file memorizzati nella cache.

Se si utilizzano più farm, ogni farm deve utilizzare un documento principale diverso.

Denominazione del file di stato

La proprietà /statfile identifica il file da utilizzare come file di stato. Il dispatcher utilizza questo file per registrare l'ora dell'aggiornamento del contenuto più recente. Il file di stato può essere un qualsiasi file sul server Web.

Il file di stato non ha contenuto. Quando il contenuto viene aggiornato, il dispatcher aggiorna la marca temporale. Il file di stato predefinito è denominato .stat e viene memorizzato nel docroot. Il dispatcher blocca l'accesso al file di stato.

Trasmissione di documenti non aggiornati in caso di errori

La proprietà /serveStaleOnError controlla se il dispatcher restituisce documenti invalidati quando il server di rendering restituisce un errore. Per impostazione predefinita, quando un file di stato viene toccato e invalida il contenuto memorizzato nella cache, il dispatcher elimina il contenuto memorizzato nella cache al successivo richiamo.

Se /serveStaleOnError è impostato su "1", il dispatcher non elimina il contenuto invalidato dalla cache a meno che il server di rendering non restituisca una risposta corretta. Una risposta 5xx da AEM o un timeout di connessione causa la distribuzione del contenuto obsoleto da parte del dispatcher e la risposta con uno stato HTTP 111 (revoca non riuscita).

Memorizzazione nella cache quando viene utilizzata l'autenticazione

La proprietà /allowAuthorized controlla se le richieste contenenti una delle seguenti informazioni di autenticazione sono memorizzate nella cache:

• L'intestazione authorization
• Un cookie denominato authorization
• Un cookie denominato login-token

Per impostazione predefinita, le richieste che includono queste informazioni di autenticazione non vengono memorizzate nella cache perché l'autenticazione non viene eseguita quando un documento memorizzato nella cache viene restituito al client. Questa configurazione impedisce al dispatcher di distribuire i documenti memorizzati nella cache agli utenti che non dispongono dei diritti necessari.

Tuttavia, se i requisiti in uso consentono il caching dei documenti autenticati, impostare /allowAuthorized su uno:

/allowAuthorized "1"

Specifica dei documenti da memorizzare nella cache

La proprietà /rules controlla quali documenti vengono memorizzati nella cache in base al percorso del documento. Indipendentemente dalla proprietà /rules, il dispatcher non memorizza mai nella cache un documento nelle seguenti circostanze:

• Se l'URI della richiesta contiene un punto interrogativo (?).

  • In genere indica una pagina dinamica, ad esempio un risultato di ricerca che non deve essere memorizzato nella cache.

• Se manca l’estensione del file.

  • Il server web ha bisogno dell’estensione per determinare il tipo di documento (tipo MIME).

• Se l’intestazione di autenticazione è impostata (configurabile)…

• Se l'istanza AEM risponde con le seguenti intestazioni:

  • no-cache
  • no-store
  • must-revalidate

Ogni elemento della proprietà /rules include un pattern glob e un tipo:

• Il pattern glob viene utilizzato per corrispondere al percorso del documento.
• Il tipo indica se memorizzare nella cache i documenti che corrispondono al pattern glob. Il valore può essere consentito (per memorizzare il documento nella cache) o negato (per eseguire sempre il rendering del documento).

Se non disponete di pagine dinamiche (oltre a quelle già escluse dalle regole di cui sopra), potete configurare Dispatcher per memorizzare tutto nella cache. La sezione relativa alle regole si presenta come segue:

/rules
  {
    /0000  {  /glob "*"   /type "allow" }
  }

Per ulteriori informazioni sulle proprietà del tipo: vedere Progettazione di pattern per le proprietà del tipo di nodo .

Se alcune sezioni della pagina sono dinamiche (ad esempio un’applicazione di notizie) o all’interno di un gruppo di utenti chiuso, è possibile definire eccezioni:

/rules
  {
   /0000  { /glob "*" /type "allow" }
   /0001  { /glob "/en/news/*" /type "deny" }
   /0002  { /glob "*/private/*" /type "deny"  }
  }

Compressione

Sui server Web Apache è possibile comprimere i documenti memorizzati nella cache. La compressione consente ad Apache di restituire il documento in un modulo compresso, se richiesto dal client. La compressione viene eseguita automaticamente attivando il modulo Apache mod_deflate, ad esempio:

AddOutputFilterByType DEFLATE text/plain

Il modulo è installato per impostazione predefinita con Apache 2.x.

Annullamento della validità dei file in base al livello di cartella

Utilizzare la proprietà /statfileslevel per annullare la validità dei file memorizzati nella cache in base al percorso:

• Il dispatcher crea .statfile in ciascuna cartella dalla cartella del docroot al livello specificato. La cartella docroot è di livello 0.

• I file vengono invalidati toccando il file .stat. L'ultima data di modifica del file .stat viene confrontata con l'ultima data di modifica di un documento memorizzato nella cache. Il documento viene recuperato se il file .stat è più recente.

• Quando un file che si trova a un determinato livello viene invalidato, tutti i file a1/> .stat dal docroot a verranno toccati il livello del file invalidato o quello configurato statsfilevel (se inferiore).

  • Ad esempio: se si imposta la proprietà statfileslevel su 6 e un file viene invalidato al livello 5, ogni file .stat da docroot a 5 verrà toccato. Se si continua con questo esempio, se un file viene invalidato al livello 7 allora ogni . stat file da docroot a 6 sarà toccato (da allora /statfileslevel = "6").

Vengono interessate solo le risorse lungo il percorso del file invalidato. Considerate l'esempio seguente: un sito Web utilizza la struttura /content/myWebsite/xx/. Se si imposta statfileslevel come 3, viene creato un file .statcome segue:

• docroot
• /content
• /content/myWebsite
• /content/myWebsite/*xx*

Quando un file in /content/myWebsite/xx viene invalidato, viene toccato ogni .stat file dal punto di vista docroot a /content/myWebsite/xx. Questo è il caso solo per /content/myWebsite/xx e non per esempio /content/myWebsite/yy o /content/anotherWebSite.

Annullamento automatico della validità dei file memorizzati nella cache

La proprietà /invalidate definisce i documenti che vengono automaticamente invalidati quando il contenuto viene aggiornato.

Con l'annullamento della validità automatica, il dispatcher non elimina i file memorizzati nella cache dopo un aggiornamento del contenuto, ma ne verifica la validità alla successiva richiesta. I documenti nella cache che non vengono annullati automaticamente rimarranno nella cache finché un aggiornamento del contenuto non li eliminerà in modo esplicito.

L'annullamento della validità automatica viene in genere utilizzato per le pagine HTML. Le pagine HTML spesso contengono collegamenti verso altre pagine, rendendo difficile determinare se un aggiornamento del contenuto influisce su una pagina. Per fare in modo che tutte le pagine pertinenti vengano invalidate quando viene aggiornato il contenuto, annullate automaticamente tutte le pagine HTML. La configurazione seguente invalida tutte le pagine HTML:

  /invalidate
  {
   /0000  { /glob "*" /type "deny" }
   /0001  { /glob "*.html" /type "allow" }
  }

Per ulteriori informazioni sulle proprietà del tipo: vedere Progettazione di pattern per le proprietà del tipo di nodo .

Questa configurazione causa la seguente attività quando /content/wknd/us/en è attivato:

• Tutti i file con pattern en.* vengono rimossi dalla cartella /content/wknd/us.
• La cartella /content/wknd/us/en./_jcr_content viene rimossa.
• Tutti gli altri file che corrispondono alla configurazione /invalidate non vengono eliminati immediatamente. Questi file vengono eliminati quando si verifica la richiesta successiva. Nel nostro esempio /content/wknd.html non viene eliminato, verrà eliminato quando /content/wknd.html viene richiesto.

Se offrite per il download file PDF e ZIP generati automaticamente, potreste dover annullare automaticamente anche questi. Esempio di configurazione:

/invalidate
  {
   /0000 { /glob "*" /type "deny" }
   /0001 { /glob "*.html" /type "allow" }
   /0002 { /glob "*.zip" /type "allow" }
   /0003 { /glob "*.pdf" /type "allow" }
  }

L'integrazione AEM con Adobe Analytics fornisce i dati di configurazione in un file analytics.sitecatalyst.js del sito Web. Il file di esempio dispatcher.any fornito con Dispatcher include la seguente regola di annullamento della validità per il file:

{
   /glob "*/analytics.sitecatalyst.js"  /type "allow"
}

Uso di script di annullamento della validità personalizzati

La proprietà /invalidateHandler consente di definire uno script che viene chiamato per ogni richiesta di annullamento della validità ricevuta dal Dispatcher.

Viene chiamato con i seguenti argomenti:

• Handle: percorso del contenuto invalidato
• Azione - Azione di replica (ad esempio Attiva, Disattiva)
• Ambito azione azione - Ambito dell'azione di replica (vuoto, a meno che non venga inviato un'intestazione di CQ-Action-Scope: ResourceOnly, vedere Invalidazione delle pagine nella cache da AEM per ulteriori dettagli)

Questo può essere utilizzato per coprire una serie di casi d’uso diversi, ad esempio per invalidare altre cache specifiche dell’applicazione, o per gestire i casi in cui l’URL esternalizzato di una pagina e la sua posizione nel documento non corrispondono al percorso del contenuto.

Sotto lo script di esempio, ogni richiesta di annullamento della validità viene registrata in un file.

/invalidateHandler "/opt/dispatcher/scripts/invalidate.sh"

script del gestore di annullamento della convalida di esempio

#!/bin/bash

printf "%-15s: %s %s" $1 $2 $3>> /opt/dispatcher/logs/invalidate.log

Limitazione dei client in grado di cancellare la cache

La proprietà /allowedClients definisce client specifici che possono cancellare la cache. I modelli globbing vengono confrontati con il PI.

Esempio:

1. nega l'accesso a qualsiasi client
2. consente esplicitamente l'accesso al localhost

/allowedClients
  {
   /0001 { /glob "*.*.*.*"  /type "deny" }
   /0002 { /glob "127.0.0.1" /type "allow" }
  }

Per ulteriori informazioni sulle proprietà del tipo: vedere Progettazione di pattern per le proprietà del tipo di nodo .

Ignorare i parametri URL

La sezione ignoreUrlParams definisce quali parametri URL vengono ignorati quando si determina se una pagina viene memorizzata nella cache o distribuita dalla cache:

• Quando un URL di richiesta contiene parametri che vengono tutti ignorati, la pagina viene memorizzata nella cache.
• Quando un URL di richiesta contiene uno o più parametri che non vengono ignorati, la pagina non viene memorizzata nella cache.

Quando un parametro viene ignorato per una pagina, la pagina viene memorizzata nella cache la prima volta che viene richiesta la pagina. Le richieste successive per la pagina vengono servite nella cache, indipendentemente dal valore del parametro nella richiesta.

Per specificare quali parametri vengono ignorati, aggiungete le regole di gestione alla proprietà ignoreUrlParams:

• Per ignorare un parametro, create una proprietà Gestione dinamica che consenta al parametro di ignorare.
• Per evitare che la pagina venga memorizzata nella cache, create una proprietà Gestione dinamica dei tag che neghi il parametro.

Nell'esempio seguente il dispatcher ignora il parametro q, in modo che gli URL di richiesta che includono il parametro q siano memorizzati nella cache:

/ignoreUrlParams
{
    /0001 { /glob "*" /type "deny" }
    /0002 { /glob "q" /type "allow" }
}

Utilizzando il valore di esempio ignoreUrlParams, la seguente richiesta HTTP causa la memorizzazione nella cache della pagina perché il parametro q viene ignorato:

GET /mypage.html?q=5

Utilizzando il valore di esempio ignoreUrlParams, la seguente richiesta HTTP fa sì che la pagina non venga memorizzata nella cache perché il parametro p non viene ignorato:

GET /mypage.html?q=5&p=4

Per ulteriori informazioni sulle proprietà del tipo: vedere Progettazione di pattern per le proprietà del tipo di nodo .

Memorizzazione in cache delle intestazioni di risposta HTTP

La proprietà /headers consente di definire i tipi di intestazione HTTP che verranno memorizzati nella cache dal dispatcher. Nella prima richiesta a una risorsa non memorizzata nella cache, tutte le intestazioni corrispondenti a uno dei valori configurati (vedere l'esempio di configurazione seguente) vengono memorizzate in un file separato, accanto al file della cache. Nelle richieste successive alla risorsa memorizzata nella cache, le intestazioni memorizzate vengono aggiunte alla risposta.

Presentato di seguito è un esempio della configurazione predefinita:

/cache {
  ...
  /headers {
    "Cache-Control"
    "Content-Disposition"
    "Content-Type"
    "Expires"
    "Last-Modified"
    "X-Content-Type-Options"
    "Last-Modified"
  }
}

FileETag none

Autorizzazioni del file cache del dispatcher

La proprietà mode specifica quali autorizzazioni vengono applicate alle nuove directory e ai nuovi file nella cache. Questa impostazione è limitata dalla umask del processo di chiamata. È un numero ottale costruito dalla somma di uno o più dei seguenti valori:

• 0400 Consenti lettura da parte del proprietario.
• 0200 Consenti scrittura per proprietario.
• 0100 Consentire al proprietario di effettuare ricerche nelle directory.
• 0040 Consenti lettura per membri del gruppo.
• 0020 Consenti scrittura per membri del gruppo.
• 0010 Consente ai membri del gruppo di effettuare ricerche nella directory.
• 0004 Consenti lettura da parte di altri.
• 0002 Consentire la scrittura da parte di altri.
• 0001 Consentire ad altri di effettuare ricerche nella directory.

Il valore predefinito è 0755 che consente al proprietario di leggere, scrivere o cercare e al gruppo e ad altri di leggere o cercare.

Limitazione del tocco di file .stat

Con la proprietà /invalidate predefinita, ogni attivazione invalida di fatto tutti i file .html (quando il percorso corrisponde alla sezione /invalidate). In un sito Web con traffico considerevole, più attivazioni successive aumenteranno il carico di CPU sul back-end. In questo caso, è consigliabile "rallentare" .stat il tocco del file per mantenere il sito Web reattivo. A tal fine è possibile utilizzare la proprietà /gracePeriod.

La proprietà /gracePeriod definisce il numero di secondi per i quali una risorsa non aggiornata e con annullamento automatico può ancora essere servita dalla cache dopo l'ultima attivazione. La proprietà può essere utilizzata in una configurazione in cui un batch di attivazioni in caso contrario annullerebbe ripetutamente l'intera cache. Il valore consigliato è 2 secondi.

Per ulteriori dettagli, consultare anche le sezioni /invalidate e /statfileslevelriportate sopra.

Configurazione dell'annullamento della validità della cache in base al tempo - /enableTTL

Se impostata, la proprietà /enableTTL valuterà le intestazioni di risposta dal back-end, e se contengono una Cache-Control pagina massima o Expires data, viene creato un file ausiliario vuoto accanto al file della cache, con un tempo di modifica uguale alla data di scadenza. Quando il file memorizzato nella cache viene richiesto oltre l'ora di modifica, viene automaticamente richiesto nuovamente dal back-end.

Configurazione del bilanciamento del carico - /statistics

La sezione /statistics definisce le categorie di file per i quali Dispatcher valuta la reattività di ciascun rendering. Il dispatcher utilizza i punteggi per determinare quale rendering inviare una richiesta.

Per ogni categoria creata viene definito un pattern di tipo Gap. Dispatcher confronta l'URI del contenuto richiesto con i seguenti pattern per determinare la categoria del contenuto richiesto:

• L'ordine delle categorie determina l'ordine in cui vengono confrontate con l'URI.
• Il primo pattern di categoria che corrisponde all’URI è la categoria del file. Non vengono valutati altri pattern di categoria.

Il dispatcher supporta un massimo di 8 categorie di statistiche. Se definite più di 8 categorie, vengono utilizzate solo le prime 8.

Rendering selezione

Ogni volta che il dispatcher richiede una pagina di cui è stato effettuato il rendering, utilizza il seguente algoritmo per selezionare il rendering:

1. Se la richiesta contiene il nome di rendering in un cookie renderid, il dispatcher utilizza tale rendering.

2. Se la richiesta non include cookie renderid, Dispatcher confronta le statistiche di rendering:

   1. Il dispatcher determina la categoria dell'URI della richiesta.
   2. Il dispatcher determina quale rendering ha il punteggio di risposta più basso per quella categoria e lo seleziona.

3. Se non è ancora selezionato alcun rendering, usate il primo rendering nell’elenco.

La valutazione per la categoria di un rendering è basata sui tempi di risposta precedenti, nonché sulle connessioni non riuscite e di successo precedenti tentate dal dispatcher. Per ogni tentativo, il punteggio per la categoria dell'URI richiesto viene aggiornato.

Definizione delle categorie di statistiche

Definire una categoria per ciascun tipo di documento per il quale si desidera mantenere le statistiche per la selezione del rendering. La sezione /statistics contiene una sezione /categories. Per definire una categoria, aggiungere una riga sotto la sezione /categories con il seguente formato:

/name { /glob "pattern"}

La categoria name deve essere univoca per la farm. La sezione pattern è descritta nella sezione Progettazione di pattern per Proprietà di tipo _bit.

Per determinare la categoria di un URI, Dispatcher confronta l'URI con ciascun pattern di categoria fino a trovare una corrispondenza. Il dispatcher inizia con la prima categoria nell'elenco e continua in ordine. Pertanto, inserite prima le categorie con pattern più specifici.

Ad esempio, Dispatcher il file dispatcher.any predefinito definisce una categoria HTML e un'altra. La categoria HTML è più specifica e quindi viene visualizzata per prima:

/statistics
  {
  /categories
    {
      /html { /glob "*.html" }
      /others  { /glob "*" }
    }
  }

L’esempio seguente include anche una categoria per le pagine di ricerca:

/statistics
  {
  /categories
    {
      /search { /glob "*search.html" }
      /html { /glob "*.html" }
      /others  { /glob "*" }
    }
  }

Riflesso dell'indisponibilità del server nelle statistiche del dispatcher

La proprietà /unavailablePenalty imposta il tempo (in decimi di secondo) applicato alle statistiche di rendering quando una connessione al rendering non riesce. Il dispatcher aggiunge l'ora alla categoria delle statistiche che corrisponde all'URI richiesto.

Ad esempio, la sanzione viene applicata quando non è possibile stabilire la connessione TCP/IP alla porta/nome host designata, perché AEM non è in esecuzione (e non è in ascolto) o a causa di un problema di rete.

La proprietà /unavailablePenalty è un elemento secondario diretto della sezione /farm (un elemento di pari livello della sezione /statistics).

Se non esiste alcuna proprietà /unavailablePenalty, viene utilizzato un valore di "1".

/unavailablePenalty "1"

Identificazione di una cartella di connessione fissa - /stickyConnectionsFor

La proprietà /stickyConnectionsFor definisce una cartella contenente documenti fissi; l’accesso verrà eseguito utilizzando l’URL. Il dispatcher invia tutte le richieste, da un singolo utente, che si trovano in questa cartella alla stessa istanza di rendering. Le connessioni permanenti garantiscono la presenza e la coerenza dei dati della sessione per tutti i documenti. Questo meccanismo utilizza il cookie renderid.

L'esempio seguente definisce una connessione fissa alla cartella /products:

/stickyConnectionsFor "/products"

Quando una pagina è composta da contenuto proveniente da più nodi di contenuto, includete la proprietà /paths che elenca i percorsi del contenuto. Ad esempio, una pagina contiene il contenuto di /content/image, /content/video e /var/files/pdfs. La seguente configurazione abilita connessioni fisse per tutto il contenuto della pagina:

/stickyConnections {
  /paths {
    "/content/image"
    "/content/video"
    "/var/files/pdfs"
  }
}

httpOnly

Quando sono attivate le connessioni sticky, il modulo dispatcher imposta il cookie renderid. Questo cookie non ha il flag httponly, che deve essere aggiunto per migliorare la sicurezza. È possibile eseguire questa operazione impostando la proprietà httpOnly nel nodo /stickyConnections di un file di configurazione dispatcher.any. Il valore della proprietà (0 o 1) definisce se al cookie renderid è associato l'attributo HttpOnly. Il valore predefinito è 0, ovvero l'attributo non verrà aggiunto.

Per ulteriori informazioni sul flag httponly, leggere questa pagina.

secure

Quando sono attivate le connessioni sticky, il modulo dispatcher imposta il cookie renderid. Questo cookie non ha il flag secure, che deve essere aggiunto per migliorare la sicurezza. È possibile eseguire questa operazione impostando la proprietà secure nel nodo /stickyConnections di un file di configurazione dispatcher.any. Il valore della proprietà (0 o 1) definisce se al cookie renderid è associato l'attributo secure. Il valore predefinito è 0, il che significa che l'attributo verrà aggiunto se la richiesta in arrivo è sicura. Se il valore è impostato su 1, il flag secure verrà aggiunto indipendentemente dal fatto che la richiesta in entrata sia protetta o meno.

Gestione degli errori di connessione di rendering

Configura il comportamento del dispatcher quando il server di rendering restituisce un errore 500 o non è disponibile.

Specifica di una pagina di verifica dello stato

Utilizzare la proprietà /health_check per specificare un URL controllato quando si verifica un codice di stato 500. Se questa pagina restituisce anche un codice di stato 500, l'istanza viene considerata non disponibile e al rendering viene applicata una penale per l'ora configurabile ( /unavailablePenalty) prima di riprovare.

/health_check
  {
  # Page gets contacted when an instance returns a 500
  /url "/health_check.html"
  }

Specifica del ritardo del tentativo di pagina

La proprietà /retryDelay imposta il tempo (in secondi) che il Dispatcher attende tra i cicli di tentativi di connessione con i rendering della farm. Per ogni arrotondamento, il numero massimo di tentativi di dispatcher di creare una connessione a un rendering corrisponde al numero di rendering nella farm.

Il dispatcher utilizza un valore di "1" se /retryDelay non è definito in modo esplicito. Il valore predefinito è appropriato nella maggior parte dei casi.

/retryDelay "1"

Configurazione del numero di tentativi

La proprietà /numberOfRetries imposta il numero massimo di cicli di tentativi di connessione eseguiti da Dispatcher con i rendering. Se Dispatcher non riesce a collegarsi a un rendering dopo questo numero di tentativi, Dispatcher restituisce una risposta non riuscita.

Per ogni arrotondamento, il numero massimo di tentativi di dispatcher di creare una connessione a un rendering corrisponde al numero di rendering nella farm. Pertanto, il numero massimo di tentativi di connessione da parte del dispatcher è ( /numberOfRetries) x (il numero di rendering).

Se il valore non è definito in modo esplicito, il valore predefinito è 5.

/numberOfRetries "5"

Utilizzo del meccanismo di failover

Abilitate il meccanismo di failover nella farm del dispatcher per inviare nuovamente le richieste a diversi rendering quando la richiesta originale non riesce. Quando il failover è abilitato, il dispatcher ha il seguente comportamento:

• Quando una richiesta a un rendering restituisce lo stato HTTP 503 (NON DISPONIBILE), il dispatcher invia la richiesta a un rendering diverso.
• Quando una richiesta a un rendering restituisce lo stato HTTP 50x (diverso da 503), il dispatcher invia una richiesta per la pagina configurata per la proprietà health_check.
  • Se il controllo dello stato restituisce 500 (INTERNAL_SERVER_ERROR), il dispatcher invia la richiesta originale a un rendering diverso.
  • Se il controllo healtch restituisce lo stato HTTP 200, Dispatcher restituisce l'errore HTTP 500 iniziale al client.

Per abilitare il failover, aggiungi la seguente riga alla farm (o al sito Web):

/failover "1"

Ignorare gli errori di interruzione - /ignoreEINTR

Qualsiasi chiamata di sistema orientata al file system può essere interrotta EINTR se l'oggetto della chiamata di sistema si trova in un sistema remoto a cui si accede tramite NFS. Se queste chiamate di sistema possono essere interrotte o interrotte, si basa su come il file system sottostante è stato montato sul computer locale.

Utilizzate il parametro /ignoreEINTR se l'istanza dispone di tale configurazione e il registro contiene il messaggio seguente:

Error while reading response: Interrupted system call

Internamente, Dispatcher legge la risposta dal server remoto (ad es. AEM) utilizzando un loop che può essere rappresentato come:

while (response not finished) {  
read more data  
}

Tali messaggi possono essere generati quando EINTR si verifica nella sezione " read more data" e sono causati dalla ricezione di un segnale prima della ricezione dei dati.

Per ignorare tali interruzioni è possibile aggiungere il seguente parametro a dispatcher.any (prima di /farms):

/ignoreEINTR "1"

Se si imposta /ignoreEINTR su "1", il dispatcher continuerà a tentare di leggere i dati fino alla lettura della risposta completa. Il valore predefinito è 0 e disattiva l’opzione.

Progettazione di pattern per le proprietà di gestione

Diverse sezioni del file di configurazione del dispatcher utilizzano le proprietà glob come criteri di selezione per le richieste dei client. I valori delle proprietà glob sono pattern che il dispatcher confronta con un aspetto della richiesta, ad esempio il percorso della risorsa richiesta o l'indirizzo IP del client. Ad esempio, gli elementi della sezione /filter utilizzano i pattern glob per identificare i percorsi delle pagine su cui il dispatcher agisce o che rifiuta.

I valori glob possono includere caratteri jolly e caratteri alfanumerici per definire il pattern.

Registrazione

Nella configurazione del server Web, potete impostare:

• Posizione del file di registro del dispatcher.
• Livello di registro.

Per ulteriori informazioni, fare riferimento alla documentazione del server Web e al file Leggimi dell'istanza del Dispatcher.

Registri Apache ruotati/Piped

Se si utilizza un server Web Apache, è possibile utilizzare la funzionalità standard per i registri ruotati e/o con tubazioni. Ad esempio, utilizzando i registri con tubazioni:

DispatcherLog "| /usr/apache/bin/rotatelogs logs/dispatcher.log%Y%m%d 604800"

Questo verrà ruotato automaticamente:

• il file di registro del dispatcher; con una marca temporale nell'estensione (logs/dispatcher.log%Y%m%d).
• su base settimanale (60 x 60 x 24 x 7 = 604800 secondi).

Consulta la documentazione del server web Apache su Log Rotation e Piped Logs; ad esempio Apache 2.4.

Registrazione traccia

Tra gli altri miglioramenti apportati al dispatcher, la versione 4.2.0 introduce anche la funzione di registrazione delle tracce.

Si tratta di un livello superiore alla registrazione di debug, che mostra informazioni aggiuntive nei registri. Consente di aggiungere la registrazione per:

• I valori delle intestazioni inoltrate;
• Regola applicata per una determinata azione.

È possibile abilitare Trace Logging impostando il livello di registro su 4 nel server Web.

Di seguito è riportato un esempio di registri con traccia abilitata:

[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Host] = "localhost:8443"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[User-Agent] = "curl/7.43.0"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Accept] = "*/*"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Client-Cert] = "(null)"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Via] = "1.1 localhost:8443 (dispatcher)"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-For] = "::1"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL] = "on"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Cipher] = "DHE-RSA-AES256-SHA"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Session-ID] = "ba931f5e4925c2dde572d766fdd436375e15a0fd24577b91f4a4d51232a934ae"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-Port] = "8443"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Server-Agent] = "Communique-Dispatcher"

E un evento registrato quando viene richiesto un file che corrisponde a una regola di blocco:

[Thu Mar 03 14:42:45 2016] [T] [11831] 'GET /content.infinity.json HTTP/1.1' was blocked because of /0082

Conferma dell'operazione di base

Per confermare il funzionamento e l'interazione di base del server Web, del dispatcher e dell'istanza AEM, procedere come segue:

1. Impostare loglevel su 3.

2. Avviare il server Web; viene avviato anche il Dispatcher.

3. Avviate l'istanza AEM.

4. Controllate i file di registro e di errore del server Web e del dispatcher.

   • A seconda del server Web, dovrebbero essere visualizzati messaggi quali:
     • [Thu May 30 05:16:36 2002] [notice] Apache/2.0.50 (Unix) configured e
     • [Fri Jan 19 17:22:16 2001] [I] [19096] Dispatcher initialized (build XXXX)

5. Navigare sul sito Web tramite il server Web. Verificate che il contenuto venga visualizzato come richiesto.
   Ad esempio, in un'installazione locale in cui AEM eseguito sulla porta 4502 e sul server Web in 80, accedete alla console Siti Web utilizzando entrambi:

   • https://localhost:4502/libs/wcm/core/content/siteadmin.html
   • https://localhost:80/libs/wcm/core/content/siteadmin.html
   • I risultati devono essere identici. Confermate l'accesso ad altre pagine con lo stesso meccanismo.

6. Verificate che la directory della cache sia stata compilata.

7. Attivate una pagina per verificare che la cache venga scaricata correttamente.

8. Se tutto funziona correttamente, è possibile ridurre il loglevel a 0.

Utilizzo di più istanze di Dispatcher

In configurazioni complesse è possibile utilizzare più istanze di Dispatcher. Ad esempio, puoi utilizzare:

• un’istanza di Dispatcher per pubblicare un sito web nella Intranet;
• una seconda istanza di Dispatcher, con un indirizzo diverso e impostazioni di sicurezza diverse, per pubblicare lo stesso contenuto in Internet.

In tal caso, assicurati che ogni richiesta venga gestita tramite un’unica istanza di Dispatcher. Un’istanza di Dispatcher non gestisce le richieste provenienti da un’altra istanza di Dispatcher. Assicurati pertanto che entrambe le istanze di Dispatcher accedano direttamente al sito web AEM.

Debug

Quando si aggiunge l'intestazione X-Dispatcher-Info a una richiesta, il dispatcher risponde se la destinazione è stata memorizzata nella cache, è stata restituita dalla cache o non è possibile memorizzarla nella cache. L'intestazione della risposta X-Cache-Info contiene queste informazioni in un modulo leggibile. È possibile utilizzare queste intestazioni di risposta per risolvere i problemi relativi alle risposte memorizzate nella cache del dispatcher.

Questa funzionalità non è abilitata per impostazione predefinita, pertanto affinché l'intestazione della risposta X-Cache-Info sia inclusa, la farm deve contenere la seguente voce:

/info "1"

Esempio,

/farm
{
    /mywebsite
    {
        # Include X-Cache-Info response header if X-Dispatcher-Info is in request header
        /info "1"
    }
}

Inoltre, l'intestazione X-Dispatcher-Info non ha bisogno di un valore, ma se si utilizza curl per il test è necessario specificare un valore per inviare l'intestazione, ad esempio:

curl -v -H "X-Dispatcher-Info: true" https://localhost/content/wknd/us/en.html

Di seguito è riportato un elenco contenente le intestazioni di risposta che X-Dispatcher-Info restituiranno:

• cache
  Il file di destinazione è contenuto nella cache e il dispatcher ha stabilito che è valido per distribuirlo.
• caching
  Il file di destinazione non è contenuto nella cache e il dispatcher ha stabilito che è valido per memorizzare l'output nella cache e distribuirlo.
• caching: Il file stat è più
  recenteIl file di destinazione è contenuto nella cache, ma viene invalidato da un file di stato più recente. Il dispatcher eliminerà il file di destinazione, lo ricreerà dall'output e lo invierà.
• non memorizzabile nella cache: nessun documento
  radiceLa configurazione della farm non contiene un documento radice (elemento di configurazione
  cache.docroot).
• non memorizzabile nella cache: percorso del file cache troppo lungo
  Il file di destinazione, ovvero la concatenazione della radice del documento e del file URL, supera il nome file più lungo possibile sul sistema.
• non memorizzabile nella cache: percorso del file temporaneo troppo lungo
  Il modello di nome file temporaneo supera il nome file più lungo possibile sul sistema. Il dispatcher crea prima un file temporaneo, prima di creare o sovrascrivere effettivamente il file memorizzato nella cache. Il nome del file temporaneo è il nome del file di destinazione con i caratteri _YYYYXXXXXX aggiunti al file, dove Y e X verranno sostituiti per creare un nome univoco.
• non memorizzabile nella cache: l'URL della richiesta non ha estensione
  L'URL della richiesta non ha alcuna estensione, oppure esiste un percorso dopo l'estensione del file, ad esempio: /test.html/a/path.
• non memorizzabile nella cache: La richiesta non era un metodo GET o
  HEADTil metodo HTTP non è né un GET né un HEAD. Il dispatcher presume che l'output conterrà dati dinamici che non dovrebbero essere memorizzati nella cache.
• non memorizzabile nella cache: la richiesta conteneva una stringa di query
  La richiesta conteneva una stringa di query. Il dispatcher presuppone che l'output dipenda dalla stringa di query specificata e pertanto non memorizza nella cache.
• non memorizzabile nella cache: session manager non autenticato
  La cache della farm è gestita da un manager sessione (la configurazione contiene un nodo sessionmanagement) e la richiesta non conteneva le informazioni di autenticazione appropriate.
• non memorizzabile nella cache: la richiesta contiene l'autorizzazione
  La farm non può memorizzare nella cache l'output ( allowAuthorized 0) e la richiesta contiene informazioni sull'autenticazione.
• non memorizzabile nella cache: target è una directory
  Il file di destinazione è una directory. Ciò potrebbe indicare un errore concettuale, in cui un URL e alcuni URL secondari contengono entrambi output memorizzabili nella cache, ad esempio se una richiesta a /test.html/a/file.ext viene prima e contiene output memorizzabile nella cache, il dispatcher non sarà in grado di memorizzare nella cache l'output di una richiesta successiva a /test.html.
• non memorizzabile nella cache: l'URL della richiesta ha una barra finale
  L’URL della richiesta dispone di una barra finale.
• non memorizzabile nella cache: URL richiesta non presente nelle regole della cache
  Le regole della cache della farm negano esplicitamente la memorizzazione nella cache dell'output di alcuni URL di richieste.
• non memorizzabile nella cache: accesso negato al controllo dell'autorizzazione
  Il controllo delle autorizzazioni della farm ha negato l'accesso al file memorizzato nella cache.
• non memorizzabile nella cache: session non
  validaLa cache della farm è gestita da un gestore di sessione (la configurazione contiene un sessionmanagement nodo) e la sessione dell'utente non è o non è più valida.
• non memorizzabile nella cache: la risposta contieneno_cache
  Il server remoto ha restituito un
  Dispatcher: no_cache intestazione, divieto del dispatcher di memorizzare nella cache l'output.
• non memorizzabile nella cache: la lunghezza del contenuto della risposta è
  zeroLa lunghezza del contenuto della risposta è zero; il dispatcher non creerà un file di lunghezza zero.