Configuration de Dispatcher

Les sections suivantes décrivent comment configurer divers aspects du Dispatcher.

Prise en charge d’IPv6 et IPv4

Vous pouvez installer tous les éléments d’AEM et de Dispatcher sur des réseaux IPv4 et IPv6. Voir IPV4 et IPV6.

Fichiers de configuration de Dispatcher

Par défaut, la configuration de Dispatcher est stockée dans le fichier texte dispatcher.any, bien que vous puissiez modifier le nom et l’emplacement de ce fichier au cours de l’installation.

Le fichier de configuration contient une série de propriétés à une ou plusieurs valeurs qui contrôlent le comportement de Dispatcher :

• Les noms des propriétés comportent un préfixe avec une barre oblique /.
• Les propriétés à plusieurs valeurs placent les éléments enfants dans des accolades { }.

Une configuration peut être structurée comme suit :

# 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"
     }
 }

Vous pouvez inclure d’autres fichiers qui contribuent à la configuration :

• Si votre fichier de configuration est volumineux, vous pouvez le diviser en plusieurs fichiers plus petits (plus faciles à gérer) et les inclure chacun.
• Pour inclure des fichiers générés automatiquement.

Par exemple, pour inclure le fichier myFarm.any dans la configuration de /farms, utilisez le code suivant :

/farms
  {
  $include "myFarm.any"
  }

Pour spécifier une plage de fichiers à inclure, utilisez l’astérisque (*) comme caractère générique.

Par exemple, si les fichiers allant de farm_1.any à farm_5.any contiennent la configuration de fermes de serveurs un à cinq, vous pouvez les inclure comme suit :

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

Utilisation de variables d’environnement

Vous pouvez utiliser des variables d’environnement dans des propriétés à valeur de chaîne dans le fichier dispatcher.any au lieu de coder en dur les valeurs. Pour inclure la valeur d’une variable d’environnement, utilisez le format ${variable_name}.

Par exemple, si le fichier dispatcher.any se trouve dans le même répertoire que le répertoire du cache, la valeur suivante pour la variable docroot peut être utilisée :

/docroot "${PWD}/cache"

Autre exemple : si vous créez une variable d’environnement nommée PUBLISH_IP qui stocke le nom d’hôte de l’instance de publication AEM, la configuration de la propriété /renders suivante peut être utilisée :

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

Attribution d’un nom à l’instance de Dispatcher

Utilisez la propriété /name pour indiquer un nom unique permettant d’identifier votre instance de Dispatcher. La propriété /name est une propriété de niveau supérieur dans la structure de configuration.

Définition des fermes de serveurs

La propriété /farms définit un ou plusieurs groupes de comportements de Dispatcher, chaque groupe étant associé à différents sites web ou URL. La propriété /farms peut inclure une ou plusieurs fermes de serveurs :

• Utilisez une seule ferme de serveurs lorsque vous souhaitez que Dispatcher traite toutes vos pages ou tous vos sites web de la même manière.
• Créez plusieurs fermes de serveurs lorsque différentes zones de votre site web ou différents sites web nécessitent un comportement Dispatcher différent.

La propriété /farms est une propriété de niveau supérieur dans la structure de configuration. Pour définir une ferme de serveurs, ajoutez une propriété enfant à la propriété /farms. Utilisez un nom de propriété qui identifie la ferme de serveurs de manière unique dans l’instance de Dispatcher.

La propriété /farmname est composée de plusieurs valeurs et contient d’autres propriétés définissant le comportement de Dispatcher :

• URL des pages auxquelles s’applique la ferme de serveurs.
• Une ou plusieurs URL de service (généralement des instances de publication AEM) à utiliser pour le rendu des documents.
• Statistiques à utiliser pour l’équilibrage de charge de plusieurs rendus de document.
• Plusieurs autres comportements, tels que les fichiers à mettre en cache et l’emplacement de mise en cache.

La valeur peut contenir n’importe quel caractère alphanumérique (a-z, 0-9). L’exemple suivant montre la définition du squelette pour deux fermes de serveurs appelées /daycom et /docsdaycom :

#name of dispatcher
/name "day sites"

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

Chaque propriété /farm peut contenir les propriétés enfants suivantes :

Spécification d’une page par défaut (IIS uniquement) - /homepage

Spécification des en-têtes HTTP à transférer

La propriété /clientheaders définit une liste d’en-têtes HTTP que Dispatcher transfère de la demande HTTP client vers le rendu (instance AEM).

Par défaut, Dispatcher transfère les en-têtes HTTP standard vers l’instance AEM. Dans certains cas, vous pouvez transférer des en-têtes supplémentaires ou supprimer des en-têtes spécifiques :

• Ajoutez des en-têtes, tels que des en-têtes personnalisés, que votre instance AEM attend dans la requête HTTP.
• Supprimez les en-têtes, tels que les en-têtes d’authentification qui ne concernent que le serveur web.

Si vous personnalisez l’ensemble d’en-têtes à transférer, vous devez spécifier une liste complète d’en-têtes, y compris ceux qui sont normalement inclus par défaut.

Par exemple, une instance de Dispatcher qui gère les demandes d’activation de pages pour les instances de publication nécessite l’en-tête PATH dans la section /clientheaders. Le PATH L’en-tête permet la communication entre l’agent de réplication et Dispatcher.

Le code suivant est un exemple de configuration pour /clientheaders :

/clientheaders
  {
  "CSRF-Token"
  "X-Forwarded-Proto"
  "referer"
  "user-agent"
  "authorization"
  "from"
  "content-type"
  "content-length"
  "accept-charset"
  "accept-encoding"
  "accept-language"
  "accept"
  "host"
  "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"
  }

Identification des hôtes virtuels 

La propriété /virtualhosts définit une liste de toutes les combinaisons de nom d’hôte/URI que Dispatcher accepte pour cette ferme de serveurs. Vous pouvez utiliser l’astérisque (*) comme caractère générique. Les valeurs de la propriété /virtualhosts utilisent le format suivant :

[scheme]host[uri][*]

• scheme : (facultatif) soit https:// soit https://.
• host : nom ou adresse IP de l’ordinateur hôte ainsi que le numéro de port, le cas échéant. (Voir https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23)
• uri : (facultatif) chemin d’accès aux ressources.

L’exemple de configuration suivant traite les demandes pour la variable .com et .ch Domaines de myCompany et tous les domaines de mySubDivision :

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

La configuration suivante traite toutes les demandes :

   /virtualhosts
    {
    "*"
    }

Résolution de l’hôte virtuel

Lorsque Dispatcher reçoit une requête HTTP ou HTTPS, il trouve la valeur d’hôte virtuel qui correspond le mieux aux en-têtes host,, uri et scheme de la requête. Dispatcher évalue les valeurs dans les propriétés virtualhosts dans l’ordre suivant :

• Dispatcher commence par la ferme de serveurs la moins élevée et progresse vers les valeurs plus élevées dans le fichier dispatcher.any.
• Pour chaque ferme de serveurs, Dispatcher commence par la valeur la plus élevée de la propriété virtualhosts et progresse vers les valeurs moins élevées de la liste.

Dispatcher détecte la valeur d’hôte virtuel correspondant le mieux comme suit :

• L’hôte virtuel rencontré en premier qui correspond aux parties host, scheme et uri de la demande est utilisé.
• Si non virtualhosts les valeurs ont scheme et uri parties qui correspondent toutes deux à la variable scheme et uri de la requête, l’hôte virtuel rencontré en premier qui correspond à la variable host de la requête est utilisée.
• Si aucune valeur virtualhosts ne comporte une partie host qui correspond à la partie host de la demande, l’hôte virtuel le plus élevé de la ferme de serveurs la plus élevée est utilisé.

Par conséquent, vous devez définir l’hôte virtuel par défaut dans la partie supérieure de la propriété virtualhosts dans la ferme de serveurs la plus élevée de votre fichier dispatcher.any

Exemple de résolution du nom d’hôte virtuel

L’exemple suivant représente un extrait de code d’une dispatcher.any fichier qui définit deux fermes de serveurs de Dispatcher et chaque ferme définit une 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"
      }
    }
  }

En utilisant cet exemple, le tableau suivant affiche les hôtes virtuels qui sont résolus pour les requêtes HTTP données :

Activation des sessions sécurisées - /sessionmanagement

Créez une session sécurisée pour l’accès à la ferme de serveurs de rendu, de sorte que les utilisateurs doivent se connecter pour accéder à n’importe quelle page de la ferme de serveurs. Après avoir ouvert une session, les utilisateurs peuvent accéder à toutes les pages de la ferme de serveurs. Voir Création d’un groupe d’utilisateurs fermé pour plus d’informations sur l’utilisation de cette fonctionnalité avec les CUG. Consultez également la Liste de contrôle de sécurité de Dispatcher avant la mise en ligne.

La propriété /sessionmanagement est une sous-propriété de /farms.

/sessionmanagement comporte plusieurs sous-paramètres :

/directory (obligatoire)

Répertoire qui stocke les informations de session. Si le répertoire n’existe pas, il est créé.

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

/encode (facultatif)

Mode de codage des informations de session. Utilisation md5 pour le chiffrement à l’aide de l’algorithme md5, ou hex pour le codage hexadécimal. Si vous chiffrez les données de session, un utilisateur ayant accès au système de fichiers ne peut pas lire le contenu de la session. La valeur par défaut est md5.

/header (facultatif)

Nom de l’en-tête HTTP ou du cookie qui stocke les informations d’autorisation. Si vous stockez les informations dans l’en-tête http, utilisez HTTP:<header-name>. Pour stocker les informations dans un cookie, utilisez Cookie:<header-name>. Si vous ne spécifiez pas de valeur, HTTP:authorization est utilisée.

/timeout (facultatif)

Le nombre de secondes avant que la session ne s’arrête une fois qu’elle a été utilisée en dernier. Non spécifié "800" est utilisée, de sorte que la session expire un peu plus de 13 minutes après la dernière requête de l’utilisateur.

Voici un exemple de configuration :

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

Définition des rendus de page

La propriété /renders définit l’URL à laquelle Dispatcher envoie les demandes de rendu d’un document. La section d’exemple suivante /renders identifie une seule instance AEM pour le rendu :

/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 section d’exemple suivante /renders identifie une instance AEM qui s’exécute sur le même ordinateur que Dispatcher :

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

La section d’exemple suivante /renders répartit les demandes de rendu à égalité entre deux instances AEM :

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

Options de rendu

/timeout

Indique le délai de connexion (en millisecondes) pour accéder à l’instance AEM. La valeur par défaut est "0", ce qui entraîne l’attente indéfinie de Dispatcher.

/receiveTimeout

Indique la durée (en millisecondes) autorisée d’une réponse. La valeur par défaut est "600000", ce qui entraîne l’attente de Dispatcher pendant 10 minutes. Un paramètre de "0" élimine le délai d’expiration .

Si le délai est atteint pendant l’analyse des en-têtes de réponse, un état HTTP 504 (passerelle erronée) est renvoyé. Si le délai d’expiration est atteint pendant la lecture du corps de la réponse, Dispatcher renvoie la réponse incomplète au client. Il supprime également tout fichier cache qui peut avoir été écrit.

/ipv4

Indique si Dispatcher utilise la fonction getaddrinfo (pour IPv6) ou la fonction gethostbyname (pour IPv4) pour obtenir l’adresse IP du rendu. Une valeur de 0 provoque l’utilisation de getaddrinfo. Une valeur de 1 causes gethostbyname à utiliser. La valeur par défaut est 0.

Le getaddrinfo renvoie une liste d’adresses IP. Dispatcher itère la liste des adresses jusqu’à ce qu’elle établisse une connexion TCP/IP. Par conséquent, la variable ipv4 est importante lorsque le nom d’hôte du rendu est associé à plusieurs adresses IP et à l’hôte, en réponse à la variable getaddrinfo , renvoie une liste d’adresses IP toujours dans le même ordre. Dans ce cas, vous devez utiliser la variable gethostbyname de sorte que l’adresse IP à laquelle Dispatcher se connecte soit randomisée.

Amazon Elastic Load Balancing (ELB) est un service qui répond à getaddrinfo avec une liste d’adresses IP potentiellement dans le même ordre.

/secure

Si la variable /secure possède une valeur de "1", Dispatcher utilise HTTPS pour communiquer avec l’instance AEM. Pour plus de détails, voir aussi Configuration de Dispatcher pour l’utilisation de SSL.

/always-resolve

Avec la version 4.1.6 de Dispatcher, vous pouvez configurer la propriété /always-resolve comme suit :

• Lorsque la variable est définie sur "1", il résout le nom d’hôte sur chaque demande (Dispatcher ne met jamais en cache d’adresse IP). Il peut y avoir un léger impact sur les performances en raison de l’appel supplémentaire nécessaire pour obtenir les informations d’hôte pour chaque requête.
• Si la propriété n’est pas définie, l’adresse IP est mise en cache par défaut.

En outre, cette propriété peut être utilisée si vous rencontrez des problèmes de résolution IP dynamique, comme illustré dans l’exemple suivant :

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

Configuration de l’accès au contenu

Utilisez la section /filter pour définir les requêtes HTTP que Dispatcher accepte. Les autres demandes sont renvoyées au serveur web avec le code d’erreur 404 (page introuvable). Si aucune section /filter n’existe, toutes les demandes sont acceptées.

Remarque : les demandes pour le fichier stat sont toujours rejetées.

Le /filter se compose d’une série de règles qui refusent ou autorisent l’accès au contenu en fonction des modèles de la partie ligne de demande de la requête HTTP. Utilisez une stratégie de liste autorisée pour votre /filter section :

• Tout d'abord, refusez l'accès à tout.
• Autoriser l’accès au contenu selon les besoins.

Définition d’un filtre

Chaque élément de la section /filter comprend un type et un modèle associé à un élément spécifique de la ligne de requête ou à l’intégralité de la ligne de demande. Chaque filtre peut contenir les éléments suivants :

• Type : la propriété /type indique s’il faut accorder ou refuser l’accès aux requêtes qui correspondent au modèle. La valeur peut être allow ou deny.

• Élément de la ligne de requête : incluez /method, /url, /query ou /protocol ainsi qu’un modèle pour le filtrage des requêtes selon ces parties spécifiques de la ligne de demande de la requête HTTP. Le filtrage sur des éléments de la ligne de demande (plutôt que sur la ligne entière) correspond à la méthode préférée de filtrage.

• Éléments avancés de la ligne de demande : depuis Dispatcher 4.2.0, quatre nouveaux éléments de filtre sont disponibles. Ces nouveaux éléments sont les suivants : /path, /selectors, /extension, et /suffix respectivement. Incluez un ou plusieurs de ces éléments pour contrôler davantage les modèles d’URL.

• Propriété glob : la propriété /glob est utilisée pour la correspondance avec l’ensemble de la ligne de demande de la requête HTTP.

Partie de la ligne de demande des requêtes HTTP

HTTP/1.1 définit la variable request-line comme suit :

Method Request-URI HTTP-Version<CRLF>

Le <CRLF> Les caractères représentent un retour chariot suivi d’un saut de ligne. L’exemple suivant est la ligne de demande reçue lorsqu’un client demande la page en anglais américain du site WKND :

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

Vos modèles doivent prendre en compte les espaces dans la ligne de demande et dans la variable <CRLF> caractères.

Guillemets doubles contre guillemets simples

Lors de la création de vos règles de filtrage, utilisez des guillemets doubles "pattern" pour les motifs simples. Si vous utilisez Dispatcher 4.2.0 ou version ultérieure et que votre motif inclut une expression régulière, vous devez placer l’expression régulière '(pattern1|pattern2)' entre des guillemets simples.

Expressions régulières

Dans les versions de Dispatcher ultérieures à la version 4.2.0, vous pouvez inclure des expressions régulières POSIX étendues dans vos modèles de filtre.

Résolution des problèmes de filtres

Si vos filtres ne se déclenchent pas comme prévu, activez Journalisation de trace sur Dispatcher afin que vous puissiez voir quel filtre intercepte la requête.

Exemple de filtre : Tout refuser

La section d’exemple de filtre suivante entraîne Dispatcher à refuser les demandes pour tous les fichiers. Refusez l’accès à tous les fichiers, puis autorisez l’accès à des zones spécifiques.

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

Les demandes concernant une zone explicitement refusée renvoient le code d’erreur 404 (page introuvable).

Exemple de filtre : Refuser l’accès à des zones spécifiques

Les filtres vous permettent également de refuser l’accès à divers éléments, par exemple, aux pages ASP et aux zones sensibles d’une instance de publication. Le filtre suivant refuse l’accès aux pages ASP :

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

Exemple de filtre : Activer les demandes POST

L’exemple de filtre suivant permet d’envoyer des données de formulaire par la méthode POST :

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

Exemple de filtre : Activer l’accès à la console Processus

L’exemple suivant illustre un filtre utilisé pour refuser l’accès externe à la console Processus :

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

Si votre instance de publication utilise un contexte d’application web (par exemple, publication), elle peut également être ajoutée à votre définition de filtre.

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

Si vous devez accéder à des pages uniques dans la zone restreinte, vous pouvez y autoriser l’accès. Par exemple, pour autoriser l’accès à l’onglet Archive dans la console Processus, ajoutez la section suivante :

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

Exemple de filtre : Utilisation d’expressions régulières

Ce filtre permet des extensions dans des répertoires de contenu non publics à l’aide d’une expression régulière, définie ici entre guillemets simples :

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

Exemple de filtre : Filtrer des éléments supplémentaires d’une URL de demande

Vous trouverez ci-dessous un exemple de règle qui bloque la saisie de contenu à partir de la variable /content path et sa sous-arborescence, à l’aide de filtres pour path, selectors et extension :

/006 {
        /type "deny"
        /path "/content/*"
        /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy|sysview|docview|query|jcr:content|_jcr_content|search|childrenlist|ext|assets|assetsearch|[0-9-]+)'
        /extension '(json|xml|html|feed))'
        }

Section d’exemple /filter

Lors de la configuration de Dispatcher, vous devez restreindre l’accès externe autant que possible. L’exemple suivant offre un accès minimal aux visiteurs externes :

• /content

• contenu divers tel que des conceptions et des bibliothèques clientes. Par exemple :

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

Après avoir créé des filtres, accès à la page de test pour vous assurer que votre instance AEM est sécurisée.

Les éléments suivants /filter de la section dispatcher.any peut être utilisé comme base dans votre Fichier de configuration de Dispatcher.

Cet exemple se base sur le fichier de configuration par défaut fourni avec Dispatcher. C’est un exemple d’utilisation dans un environnement de production. Éléments précédés de # sont désactivés (commentés). Soyez prudent si vous décidez d’activer l’un de ces éléments (en supprimant la variable # sur cette ligne). Cela peut avoir un impact sur la sécurité.

Refusez l’accès à tout, puis autorisez l’accès à des éléments spécifiques (limités) :

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

      # 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
}

Tenez compte des recommandations suivantes si vous choisissez d’étendre l’accès :

• Désactiver l’accès externe à /admin si vous utilisez la version 5.4 de CQ ou une version antérieure.

• Il faut se montrer prudent lorsque vous accordez l’accès aux fichiers dans /libs. L’accès doit être autorisé sur une base individuelle.

• Refuser l’accès à la configuration de réplication afin qu’elle ne soit pas visible :

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

• Refusez l’accès au proxy inverse de Google Gadgets :

  • /libs/opensocial/proxy*

En fonction de l’installation, il peut y avoir des ressources supplémentaires sous /libs, /apps ou ailleurs. Faites en sorte qu’elles soient disponibles. Vous pouvez utiliser le fichier access.log en tant que méthode permettant de déterminer les ressources accessibles en externe.

Restriction des chaînes de requête

Depuis la version 4.1.5 de Dispatcher, utilisez la section /filter pour limiter les chaînes de requête. Il est fortement recommandé d’autoriser explicitement les chaînes de requête et d’exclure l’allocation générique par l’intermédiaire des éléments de filtre allow.

Une seule entrée peut avoir : glob ou une combinaison de method, url, query, et version, mais pas les deux. L’exemple suivant autorise la chaîne de requête a=* et refuse toutes les autres chaînes de requête des URL qui se résolvent sur le nœud /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=*" }
}

Test de sécurité de Dispatcher

Les filtres de Dispatcher doivent bloquer l’accès aux pages et scripts suivants sur AEM instances de publication. Utilisez un navigateur web pour tenter d’ouvrir les pages suivantes en tant que visiteur du site et vérifier qu’un code 404 est renvoyé. Si un autre résultat est obtenu, ajustez vos filtres.

Le rendu de page normal doit s’afficher pour /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

Pour déterminer si l’accès en écriture anonyme est activé, lancez la commande suivante dans un terminal ou une invite de commande. Vous ne devriez pas être en mesure d’écrire des données sur le noeud.

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

Pour tenter d’invalider le cache de Dispatcher et de vous assurer que vous recevez une réponse 403 du code, exécutez la commande suivante dans un terminal ou une invite de commande :

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

Activation de l’accès aux URL de redirection vers un microsite

Configurez Dispatcher pour activer l’accès aux URL de redirection vers un microsite configurées pour vos pages AEM.

Lorsque l’accès aux URL de redirection vers un microsite est activé, Dispatcher appelle régulièrement un service qui s’exécute sur l’instance de rendu pour obtenir une liste des URL de redirection vers un microsite. Dispatcher stocke cette liste dans un fichier local. Lorsqu’une demande de page est refusée en raison d’un filtre de la section /filter, Dispatcher consulte la liste des URL de redirection vers un microsite. Si l’URL refusée se trouve dans la liste, Dispatcher autorise l’accès à l’URL de redirection vers un microsite.

Pour autoriser l’accès aux URL de redirection vers un microsite, ajoutez une section /vanity_urls à la section /farms, comme illustré dans l’exemple suivant :

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

La section /vanity_urls contient les propriétés suivantes :

• /url : chemin d’accès au service URL de redirection vers un microsite qui s’exécute sur une instance de rendu. La valeur de cette propriété doit être "/libs/granite/dispatcher/content/vanityUrls.html".

• /file : chemin d’accès au fichier local sur lequel Dispatcher stocke la liste des URL de redirection vers un microsite. Vérifiez que Dispatcher dispose d’un accès en écriture à ce fichier.

• /delay : (en secondes) durée entre les appels au service URL de redirection vers un microsite.

Utilisez la procédure suivante pour autoriser l’accès aux URL de redirection vers un microsite.

1. Si votre service de rendu est une instance AEM, installez la variable com.adobe.granite.dispatcher.vanityurl.content module sur l’instance de publication (voir la note ci-dessus).
2. Pour chaque URL de redirection vers un microsite que vous avez configurée pour une page d’AEM ou de CQ, assurez-vous que la configuration de /filter refuse l’URL. Si nécessaire, ajoutez un filtre qui refuse l’URL.
3. Ajoutez la section /vanity_urls sous la section /farms.
4. Redémarrez le serveur web Apache.

Transfert des demandes de syndication - /propagateSyndPost

Les demandes de syndication sont destinées uniquement à Dispatcher. Par défaut, elles ne sont donc pas envoyées au moteur de rendu (une instance d’AEM, par exemple).

Si nécessaire, définissez la variable /propagateSyndPost de "1" pour transférer les demandes de syndication à Dispatcher. Si les demandes POST sont définies, vous devez vous assurer qu’elles ne sont pas refusées dans la section filter.

Configuration du cache de Dispatcher - /cache

La section /cache contrôle la manière dont Dispatcher met en cache les documents. Configurez plusieurs sous-propriétés pour implémenter vos stratégies de mise en cache :

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

Un exemple de section cache pourrait ressembler à ce qui suit :

/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
    }
  }

Indication du répertoire du cache

La propriété /docroot identifie le répertoire dans lequel les fichiers mis en cache sont stockés.

Si vous utilisez plusieurs fermes de serveurs, chacune doit utiliser une racine de document différente.

Dénomination du fichier stat

La propriété /statfile identifie le fichier à utiliser en tant que fichier stat. Dispatcher utilise ce fichier pour enregistrer l’heure de la mise à jour de contenu la plus récente. Le fichier stat peut être n’importe quel fichier sur le serveur web.

Le fichier stat n’a aucun contenu. Lorsque le contenu est mis à jour, Dispatcher met à jour l’horodatage. Le fichier stat par défaut est nommé .stat et est stocké dans le docroot. Dispatcher bloque l’accès au fichier stat.

Distribution de documents obsolètes lorsque des erreurs se produisent

La propriété /serveStaleOnError contrôle si Dispatcher renvoie des documents invalidés lorsque le serveur de rendu renvoie une erreur. Par défaut, lorsqu’un fichier stat est modifié et invalide un contenu mis en cache, Dispatcher supprime le contenu mis en cache la prochaine fois qu’il est demandé.

If /serveStaleOnError est défini sur "1", Dispatcher ne supprime pas le contenu invalidé du cache, sauf si le serveur de rendu renvoie une réponse réussie. Une réponse 5xx d’AEM ou une expiration du délai de connexion entraîne Dispatcher à diffuser du contenu obsolète et à répondre avec l’état HTTP 111 (Échec de la revalidation).

Mise en cache lors de l’utilisation de l’authentification

La propriété /allowAuthorized contrôle si les demandes contenant les informations d’authentification suivantes sont mises en cache :

• Le authorization header
• Un cookie appelé authorization
• Un cookie appelé login-token

Par défaut, les demandes contenant ces informations d’authentification ne sont pas mises en cache, car l’authentification n’est pas effectuée lorsqu’un document mis en cache est renvoyé au client. Cette configuration empêche Dispatcher de diffuser des documents mis en cache aux utilisateurs qui ne disposent pas des droits nécessaires.

Toutefois, si vos besoins permettent la mise en cache de documents authentifiés, définissez /allowAuthorized en un :

/allowAuthorized "1"

Spécification des documents à mettre en cache

La propriété /rules contrôle les documents qui sont mis en cache selon le chemin d’accès au document. Quelle que soit la propriété /rules, Dispatcher ne procède jamais à la mise en cache d’un document dans les cas suivants :

• L’URI de requête contient un point d’interrogation (?).

  • Indique une page dynamique, telle qu’un résultat de recherche qui n’a pas besoin d’être mis en cache.

• L’extension de fichier est manquante.

  • Le serveur web a besoin de l’extension pour déterminer le type de document (type MIME).

• L’en-tête d’authentification est défini (configurable).

• Si l’instance AEM répond avec les en-têtes suivants :

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

Chaque élément du /rules comprend une propriété glob pattern et un type :

• Le glob est utilisé pour faire correspondre le chemin du document.
• Le type indique s’il faut mettre en cache les documents qui correspondent à la variable glob modèle. La valeur peut être allow (pour mettre le document en cache) ou deny (pour toujours effectuer le rendu du document).

Si vous ne disposez pas de pages dynamiques (au-delà des pages déjà exclues par les règles ci-dessus), vous pouvez configurer Dispatcher pour mettre tout en cache. La section Règles se présente comme suit :

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

Pour plus d’informations sur les propriétés glob, voir Création de modèles pour les propriétés glob.

Si certaines sections de votre page sont dynamiques (par exemple une application d’actualités) ou au sein d’un groupe d’utilisateurs fermé, vous pouvez définir des exceptions :

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

Compression

Sur les serveurs Web Apache, vous pouvez compresser les documents mis en cache. La compression permet à Apache de renvoyer le document sous forme compressée si cela est demandé par le client. La compression se fait automatiquement en activant le module Apache mod_deflate, par exemple :

AddOutputFilterByType DEFLATE text/plain

Le module est installé par défaut avec Apache 2.x.

Invalidation des fichiers par niveau de dossier

Utilisez la propriété /statfileslevel pour invalider une sélection de fichiers mis en cache en fonction de leur chemin d’accès :

• Dispatcher crée des fichiers.stat dans chaque dossier du dossier docroot au niveau que vous indiquez. Le dossier docroot correspond au niveau 0.

• Les fichiers sont invalidés en touchant le fichier .stat. La date de dernière modification du fichier .stat est comparée à celle d’un document mis en cache. Le document est à nouveau récupéré si le fichier .stat est plus récent.

• Lorsqu’un fichier à un certain niveau est invalidé, all .stat fichiers du docroot to le niveau du fichier invalidé ou le statsfilevel (celui qui est le plus petit) sont touchés.

  • Par exemple : si vous définissez la variable statfileslevel à 6 et qu’un fichier est invalidé au niveau 5, puis tous les .stat Le fichier de docroot à 5 est modifié. Si vous continuez avec cet exemple, si un fichier est invalidé au niveau 7, tous les stat le fichier de docroot à six est touché (puisque /statfileslevel = "6").

Uniquement les ressources le long du chemin au fichier invalidé sont affectés. Prenons l’exemple suivant : un site web utilise la structure /content/myWebsite/xx/.. Si vous définissez statfileslevel sur 3, un fichier .stat est créé comme suit :

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

Lorsque vous placez un fichier dans /content/myWebsite/xx est invalidé, puis tous les .stat fichier de docroot à /content/myWebsite/xxest touchée. Ce scénario n’est le cas que pour /content/myWebsite/xx et non par exemple /content/myWebsite/yy ou /content/anotherWebSite.

Invalidation automatique des fichiers mis en cache

La propriété /invalidate définit les documents qui sont automatiquement invalidés lorsque le contenu est mis à jour.

Avec l’invalidation automatique, Dispatcher ne supprime pas les fichiers mis en cache après une mise à jour du contenu, mais vérifie leur validité lorsqu’ils sont ensuite demandés. Les documents du cache qui ne sont pas invalidés automatiquement restent dans le cache jusqu’à ce qu’une mise à jour du contenu les supprime explicitement.

L’invalidation automatique est généralement utilisée pour les pages de HTML. Les pages de HTML contiennent souvent des liens vers d’autres pages, ce qui rend difficile de déterminer si une mise à jour du contenu affecte une page. Pour vous assurer que toutes les pages pertinentes sont invalidées lorsque le contenu est mis à jour, invalidez automatiquement toutes les pages HTML. La configuration suivante invalide toutes les pages HTML :

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

Pour plus d’informations sur les propriétés glob, voir Création de modèles pour les propriétés glob.

Cette configuration entraîne l’activité suivante lorsque /content/wknd/us/en est activé :

• Tous les fichiers avec le motif en.* sont supprimés de la variable /content/wknd/us dossier.
• Le /content/wknd/us/en./_jcr_content est supprimé.
• Tous les autres fichiers correspondant au /invalidate ne sont pas immédiatement supprimées. Ces fichiers sont supprimés lorsque la requête suivante se produit. Dans l’exemple /content/wknd.html n’est pas supprimé ; il est supprimé lorsque /content/wknd.html est demandée.

Si vous proposez des fichiers de PDF et ZIP générés automatiquement pour téléchargement, vous devrez peut-être également invalider automatiquement ces fichiers. Voici un exemple de configuration :

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

L’intégration AEM à Adobe Analytics fournit des données de configuration dans une analytics.sitecatalyst.js dans votre site web. L'exemple dispatcher.any Le fichier fourni avec Dispatcher comprend la règle d’invalidation suivante pour ce fichier :

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

Utilisation de scripts d’invalidation personnalisés

Le /invalidateHandler vous permet de définir un script appelé pour chaque demande d’invalidation reçue par Dispatcher.

Elle est appelée avec les arguments suivants :

• Handle : chemin d’accès au contenu invalidé.
• Action - Action de réplication (par exemple, Activer, Désactiver).
• Action Scope - Domaine de l’action de réplication (vide, sauf si un en-tête de CQ-Action-Scope: ResourceOnly est envoyé, voir Invalidation de pages mises en cache à partir d’AEM pour plus de détails)

Cette méthode peut être utilisée pour couvrir plusieurs cas d’utilisation différents. Par exemple, l’invalidation d’autres caches spécifiques à l’application, ou pour gérer les cas où l’URL externalisée d’une page et sa place dans le docroot, ne correspondent pas au chemin d’accès au contenu.

L’exemple de script ci-dessous consigne chaque demande d’invalidation dans un fichier.

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

Exemple de script de gestionnaire d’invalidation

#!/bin/bash

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

Limitation des clients qui peuvent vider le cache

Le /allowedClients définit des clients spécifiques autorisés à vider le cache. Les modèles d’extension métacaractère sont comparés à l’IP.

L’exemple suivant :

1. refuse l’accès à tout client ;
2. autorise explicitement l’accès à localhost.

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

Pour plus d’informations sur les propriétés glob, voir Création de modèles pour les propriétés glob.

Ignorer les paramètres d’URL

La section ignoreUrlParams définit les paramètres d’URL qui sont ignorés lorsque vous déterminez si une page est mise en cache ou exclue du cache :

• Lorsqu’une URL de requête contient des paramètres qui sont tous ignorés, la page est mise en cache.
• Lorsqu’une URL de requête contient un ou plusieurs paramètres qui ne sont pas ignorés, la page n’est pas mise en cache.

Lorsqu’un paramètre est ignoré pour une page, la page est mise en cache la première fois que la page est demandée. Les requêtes suivantes pour la page sont diffusées à la page mise en cache, quelle que soit la valeur du paramètre dans la requête.

Pour spécifier les paramètres qui sont ignorés, ajoutez les règles glob à la propriété ignoreUrlParams :

• Pour mettre en cache une page en dépit de la requête contenant un paramètre d’URL, créez une propriété glob qui permet au paramètre (d’être ignoré).
• Pour empêcher la mise en cache de la page, créez une propriété glob qui refuse le paramètre (à ignorer).

L’exemple suivant fait en sorte que Dispatcher ignore tous les paramètres, à l’exception de la variable nocache . Par conséquent, demandez des URL qui incluent la variable nocache ne sont jamais mis en cache par Dispatcher :

/ignoreUrlParams
{
    # allow-the-url-parameter-nocache-to-bypass-dispatcher-on-every-request
    /0001 { /glob "nocache" /type "deny" }
    # all-other-url-parameters-are-ignored-by-dispatcher-and-requests-are-cached
    /0002 { /glob "*" /type "allow" }
}

Dans le cadre de la ignoreUrlParams dans l’exemple de configuration ci-dessus, la requête HTTP suivante provoque la mise en cache de la page, car la variable willbecached est ignoré :

GET /mypage.html?willbecached=true

Dans le cadre de la ignoreUrlParams exemple de configuration, la requête HTTP suivante entraîne la page à not être mis en cache, car la variable nocache n’est pas ignoré :

GET /mypage.html?nocache=true
GET /mypage.html?nocache=true&willbecached=true

Pour plus d’informations sur les propriétés glob, voir Création de modèles pour les propriétés glob.

Mise en cache des en-têtes de réponse HTTP

La propriété /headers permet de définir les types d’en-têtes HTTP qui vont être mis en cache par Dispatcher. Lors de la première requête à une ressource non mise en cache, tous les en-têtes correspondant à l’une des valeurs configurées (voir l’exemple de configuration ci-dessous) sont stockés dans un fichier séparé, à côté du fichier cache. Lors des requêtes ultérieures à la ressource mise en cache, les en-têtes stockés sont ajoutés à la réponse.

Voici ci-dessous un exemple de la configuration par défaut :

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

FileETag none

Autorisations de fichier cache de Dispatcher

La propriété mode définit les autorisations de fichier appliquées aux nouveaux répertoires et fichiers du cache. Ce paramètre est limité par le umask du processus appelant. Il s’agit d’un nombre octal construit à partir de la somme d’une ou de plusieurs des valeurs suivantes :

• 0400 Autoriser la lecture par le propriétaire.
• 0200 Autoriser l’écriture par le propriétaire.
• 0100 Autoriser le propriétaire à effectuer une recherche dans les répertoires.
• 0040 Autoriser la lecture par les membres du groupe.
• 0020 Autoriser l’écriture par les membres du groupe.
• 0010 Autoriser les membres du groupe à effectuer une recherche dans le répertoire.
• 0004 Autoriser la lecture par d’autres personnes.
• 0002 Autoriser l’écriture par d’autres personnes.
• 0001 Autoriser d’autres personnes à effectuer une recherche dans le répertoire.

La valeur par défaut est 0755 qui permet au propriétaire de lire, d’écrire ou de rechercher et au groupe et à d’autres personnes de lire ou de rechercher.

Fichier limitant .stat touchant

Si la propriété /invalidate est définie par défaut, chaque activation invalide effectivement tous les fichiers .html (si leur chemin correspond à la section /invalidate). Sur un site web avec un trafic considérable, plusieurs activations ultérieures augmentent la charge du processeur sur le serveur principal. Dans un tel scénario, il est souhaitable de "ralentir" .stat pour que le site web reste réactif. Vous pouvez accomplir cette action en utilisant la variable /gracePeriod .

Le /gracePeriod définit le nombre de secondes pendant lesquelles une ressource obsolète à invalidation automatique peut toujours être diffusée à partir du cache après la dernière activation. La propriété peut être utilisée dans une configuration où un lot d’activations invaliderait de manière répétée le cache entier. La valeur recommandée est de 2 secondes.

Pour plus de détails, vous pouvez aussi lire les sections /invalidate et /statfileslevel ci-dessus.

Configuration d’une invalidation temporelle du cache - /enableTTL

L’invalidation du cache basée sur le temps dépend de la variable /enableTTL et la présence d’en-têtes d’expiration standard à partir de la norme HTTP. Si vous définissez la propriété sur 1 (/enableTTL "1"), il évalue les en-têtes de réponse du serveur principal. Si les en-têtes contiennent un Cache-Control, max-age ou Expires date, un fichier vide auxiliaire en regard du fichier mis en cache est créé, avec l’heure de modification égale à la date d’expiration. Lorsque le fichier mis en cache est demandé après l’heure de modification, il est automatiquement redemandé depuis le serveur principal.

Avant la version 4.3.5 de Dispatcher, la logique d’invalidation TTL ne reposait que sur la valeur TTL configurée. Avec Dispatcher 4.3.5, la durée de vie définie et les règles d’invalidation du cache de Dispatcher sont prises en compte. Par conséquent, pour un fichier mis en cache :

1. If /enableTTL est définie sur 1, l’expiration du fichier est vérifiée. Si le fichier a expiré conformément au délai d’activation défini, aucune autre vérification n’est effectuée et le fichier mis en cache est redemandé au serveur principal.
2. Si le fichier n’a pas expiré, ou /enableTTL n’est pas configuré, les règles d’invalidation du cache standard sont appliquées, telles que les règles définies par /statfileslevel et /invalidate. Ce flux signifie que Dispatcher peut invalider les fichiers pour lesquels la durée de vie n’a pas expiré.

Cette nouvelle mise en oeuvre prend en charge les cas d’utilisation où les fichiers ont un délai d’activation plus long (par exemple, sur le réseau de diffusion de contenu) mais peuvent toujours être invalidés même si le délai d’activation n’a pas expiré. Elle favorise l’actualisation du contenu par rapport au taux d’accès au cache sur Dispatcher.

Inversement, au cas où vous auriez besoin de only la logique d’expiration appliquée à un fichier, puis définie ; /enableTTL à 1 et excluez ce fichier du mécanisme d’invalidation du cache standard. Par exemple, vous pouvez effectuer les actions suivantes :

• Pour ignorer le fichier, configurez la variable règles d’invalidation dans la section cache . Dans le fragment de code ci-dessous, tous les fichiers se terminant par .example.html sont ignorées et expirent uniquement lorsque la durée de vie définie est dépassée.

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

• Concevez la structure de contenu de telle sorte que vous puissiez définir une valeur élevée. /statfilelevel par conséquent, le fichier n’est pas automatiquement invalidé.

Cela permet de s’assurer que .stat L’invalidation de fichier n’est pas utilisée et seule l’expiration TTL est principale pour les fichiers spécifiés.

Configuration de l’équilibrage de charge - /statistics

La section /statistics définit les catégories de fichiers pour lesquelles Dispatcher note la réactivité de chaque rendu. Dispatcher utilise les scores pour déterminer le rendu à envoyer une requête.

Chaque catégorie que vous créez définit un modèle glob. Dispatcher compare l’URI du contenu demandé à ces modèles afin de déterminer la catégorie du contenu demandé :

• L’ordre des catégories détermine l’ordre dans lequel elles sont comparées à l’URI.
• Le premier modèle de catégorie correspondant à l’URI est la catégorie du fichier. Aucun autre modèle de catégorie n’est évalué.

Dispatcher prend en charge huit catégories de statistiques au maximum. Si vous définissez plus de huit catégories, seules les 8 premières sont utilisées.

Render Selection

Chaque fois que Dispatcher requiert une page rendue, il utilise l’algorithme suivant pour sélectionner le rendu :

1. Si la demande contient le nom du rendu dans un cookie renderid, Dispatcher utilise ce rendu.

2. Si la demande n’inclut pas de cookie renderid, Dispatcher compare les statistiques de rendu :

   1. Dispatcher détermine la catégorie de l’URI de requête.
   2. Dispatcher détermine quel rendu a le score de réponse le plus bas pour cette catégorie et sélectionne ce rendu.

3. Si aucun rendu n’est encore sélectionné, utilisez le premier rendu de la liste.

Le score pour la catégorie d’un rendu est basé sur les temps de réponse précédents et les connexions précédentes ayant échoué et réussies tentées par Dispatcher. Pour chaque tentative, le score pour la catégorie de l’URI demandé est mis à jour.

Définition des catégories de statistiques

Définissez une catégorie pour chaque type de document pour lequel vous souhaitez conserver les statistiques pour la sélection du rendu. Le /statistics contient une section /categories . Pour définir une catégorie, ajoutez une ligne en dessous du champ /categories qui présente le format suivant :

/name { /glob "pattern"}

La catégorie name doit être unique à la ferme de serveurs. pattern est décrit dans la section Conception de modèles pour les propriétés glob.

Pour déterminer la catégorie d’un URI, Dispatcher compare l’URI à chaque modèle de catégorie jusqu’à ce qu’une correspondance soit trouvée. Dispatcher commence par la première catégorie de la liste et se poursuit dans l’ordre. Par conséquent, placez d’abord les catégories avec des modèles plus spécifiques.

Par exemple, Dispatcher utilise la valeur par défaut dispatcher.any définit une catégorie de HTML et une catégorie "other". La catégorie HTML est plus précise et, de ce fait, elle s’affiche en premier :

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

L’exemple suivant comprend également une catégorie pour les pages de recherche :

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

Impact de l’indisponibilité du serveur sur les statistiques de Dispatcher

La propriété /unavailablePenalty définit la durée (en dixième de seconde) qui est appliquée aux statistiques de rendu lorsqu’une connexion au rendu échoue. Dispatcher ajoute la durée à la catégorie de statistiques correspondant à l’URI demandé.

Par exemple, la pénalité est appliquée lorsque la connexion TCP/IP au nom d’hôte/port indiqué ne peut pas être établie car AEM ne fonctionne pas (et ne lit pas) ou en raison d’un problème lié au réseau.

La propriété /unavailablePenalty est un enfant direct de la section /farm (également enfant de la section /statistics).

Si non /unavailablePenalty existe, une valeur de "1" est utilisée.

/unavailablePenalty "1"

Identification d’un dossier de connexions persistantes - /stickyConnectionsFor

Le /stickyConnectionsFor définit un dossier contenant des documents persistants. Cette propriété est accessible à l’aide de l’URL. Dispatcher envoie toutes les demandes, d’un utilisateur unique qui se trouve dans ce dossier, à la même instance de rendu. Les connexions persistantes garantissent que les données de session sont présentes et cohérentes pour tous les documents. Ce mécanisme utilise le cookie renderid.

L’exemple suivant définit une connexion persistante au dossier /products :

/stickyConnectionsFor "/products"

Lorsqu’une page est constituée de contenu provenant de plusieurs nœuds de contenu, incluez la propriété /paths répertoriant les chemins d’accès au contenu. Par exemple, une page contient du contenu provenant de /content/image, /content/video et /var/files/pdfs. La configuration suivante active les connexions persistantes pour tout le contenu de la page :

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

httpOnly

Lorsque les connexions persistantes sont activées, le module Dispatcher définit la variable renderid du cookie. Ce cookie n’a pas la variable httponly indicateur , qui doit être ajouté pour améliorer la sécurité. Vous ajoutez le httponly Indicateur en définissant la variable httpOnly dans la propriété /stickyConnections noeud d’un dispatcher.any fichier de configuration. La valeur de la propriété (soit 0 ou 1) définit si la variable renderid a la variable HttpOnly Ajout de l’attribut . La valeur par défaut est 0, ce qui signifie que l’attribut n’est pas ajouté.

Pour plus d’informations sur la variable httponly indicateur, lire cette page.

secure

Lorsque les connexions persistantes sont activées, le module Dispatcher définit la variable renderid du cookie. Ce cookie n’a pas la variable secure indicateur , qui doit être ajouté pour améliorer la sécurité. Vous ajoutez le secure indicateur définissant la variable secure dans la propriété /stickyConnections noeud d’un dispatcher.any fichier de configuration. La valeur de la propriété (soit 0 ou 1) définit si la variable renderid a la variable secure Ajout de l’attribut . La valeur par défaut est 0, ce qui signifie que l’attribut est ajouté. if la requête entrante est sécurisée. Si la valeur est définie sur 1, l’indicateur sécurisé est ajouté, que la requête entrante soit sécurisée ou non.

Gestion des erreurs de connexion au serveur de rendu

Configurez le comportement de Dispatcher lorsque le serveur de rendu renvoie une erreur 500 ou n’est pas disponible.

Définition d’une page de contrôle de l’intégrité

Utilisez la propriété /health_check pour indiquer une URL qui est vérifiée lorsque le code d’état 500 se produit. Si cette page renvoie également un code d’état 500, l’instance est considérée comme indisponible et une pénalité de temps configurable ( /unavailablePenalty) est appliquée au rendu avant de réessayer.

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

Définition du délai entre deux tentatives de connexion à une page

Le /retryDelay définit le temps (en secondes) pendant lequel Dispatcher attend entre les séries de tentatives de connexion aux rendus de la ferme de serveurs. Pour chaque série, le nombre maximal de tentatives de connexion de Dispatcher à un rendu est le nombre de rendus de la ferme de serveurs.

Dispatcher utilise la valeur "1" si la propriété /retryDelay n’est pas explicitement définie. La valeur par défaut est généralement appropriée.

/retryDelay "1"

Configuration du nombre de tentatives

La propriété /numberOfRetries définit le nombre maximal de séries de tentatives de connexion que Dispatcher exécute avec les rendus. Si Dispatcher ne parvient pas à se connecter à un rendu après ce nombre de tentatives, il renvoie une réponse en échec.

Pour chaque série, le nombre maximal de tentatives de connexion de Dispatcher à un rendu est le nombre de rendus de la ferme de serveurs. Par conséquent, le nombre maximal de fois que Dispatcher tente une connexion est (/numberOfRetries) x (nombre de rendus).

Si la valeur n’est pas explicitement définie, la valeur par défaut est 5.

/numberOfRetries "5"

Utilisation du mécanisme de basculement

Pour renvoyer des requêtes à différents rendus lorsque la requête d’origine échoue, activez le mécanisme de basculement sur votre ferme de serveurs de Dispatcher. Lorsque le basculement est activé, Dispatcher se comporte comme suit :

• Lorsqu’une demande à un rendu renvoie un état HTTP 503 (INDISPONIBLE), Dispatcher envoie la demande à un autre rendu.
• Lorsqu’une demande à un rendu renvoie l’état HTTP 50x (autre que 503), Dispatcher envoie une demande pour la page qui est configurée pour la propriété health_check.
  • Si le contrôle de l’intégrité renvoie 500 (INTERNAL_SERVER_ERROR), Dispatcher envoie la demande d’origine à un autre rendu.
  • Si le contrôle de l’intégrité renvoie un état HTTP 200, Dispatcher renvoie l’erreur HTTP 500 initiale au client.

Pour activer le basculement, ajoutez la ligne suivante à la ferme de serveurs (ou au site web) :

/failover "1"

Ignorer les erreurs d’interruption - /ignoreEINTR

Tout appel système orienté fichiers peut être interrompu. EINTR si l’objet de l’appel système se trouve sur un système distant accessible au moyen de NFS. Ces appels système peuvent expirer ou être interrompus en fonction de la manière dont le système de fichiers sous-jacent a été monté sur l’ordinateur local.

Utilisez la variable /ignoreEINTR si votre instance comporte une configuration de ce type et que le journal contient le message suivant :

Error while reading response: Interrupted system call

En interne, Dispatcher lit la réponse du serveur distant (c’est-à-dire AEM) à l’aide d’une boucle qui peut être représentée comme suit :

while (response not finished) {
read more data
}

De tels messages peuvent être générés lorsque des interruptions EINTR se produisent dans la section « read more data » et sont provoqués par la réception d’un signal avant que des données n’aient été reçues.

Pour ignorer ces interruptions, vous pouvez ajouter le paramètre suivant à la variable dispatcher.any (avant /farms) :

/ignoreEINTR "1"

La définition du paramètre /ignoreEINTR sur "1" fait en sorte que Dispatcher continue d’essayer de lire des données jusqu’à la lecture de la réponse complète. La valeur par défaut est 0 et désactive l’option.

Création de modèles pour les propriétés glob

Plusieurs sections du fichier de configuration de Dispatcher utilisent les propriétés glob comme critères de sélection des demandes du client. Les valeurs de glob Les propriétés sont des modèles que Dispatcher compare à un aspect de la requête, tel que le chemin d’accès à la ressource demandée ou l’adresse IP du client. Par exemple, les éléments de la section /filter utilisent les modèles pour identifier les chemins d’accès des pages que Dispatcher traite ou rejette.glob

Le glob peuvent inclure des caractères génériques et des caractères alphanumériques pour définir le modèle.

Journalisation

Dans la configuration du serveur web, vous pouvez définir :

• L’emplacement du fichier journal de Dispatcher.
• Le niveau du journal.

Reportez-vous à la documentation du serveur web et au fichier lisez-moi de l’instance de Dispatcher pour plus d’informations.

Journaux pivotés/redirigés d’Apache

Si vous utilisez un Apache serveur web, vous pouvez utiliser la fonctionnalité standard pour les journaux pivotés, les journaux redirigés, ou les deux. Par exemple, en utilisant des journaux redirigés :

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

Cette fonctionnalité alterne automatiquement :

• le fichier journal de Dispatcher, avec un horodatage dans l’extension (logs/dispatcher.log%Y%m%d).
• chaque semaine (60 x 60 x 24 x 7 = 604 800 secondes).

Consultez la documentation du serveur web Apache sur la rotation des journaux et les journaux redirigés. Par exemple : Apache 2.4.

Journalisation de trace

Entre autres améliorations de Dispatcher, la version 4.2.0 introduit également la journalisation de trace.

Cette fonctionnalité est un niveau supérieur à la journalisation de débogage qui affiche des informations supplémentaires dans les journaux. Il ajoute la journalisation pour :

• les valeurs des en-têtes transférés ;
• à la règle appliquée pour une action.

Vous pouvez activer la journalisation de trace en définissant le niveau de journalisation sur 4 dans le serveur web.

Vous trouverez ci-dessous des exemples de journaux avec la trace activée :

[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"

Et un événement consigné lorsqu’un fichier qui correspond à une règle de blocage est demandé :

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

Confirmation du fonctionnement de base

Pour confirmer le fonctionnement de base et l’interaction du serveur web, de Dispatcher et de l’instance AEM, procédez comme suit :

1. Définissez le niveau du journal loglevel sur 3.

2. Démarrez le serveur web. Cela permet également de lancer Dispatcher.

3. Démarrez l’instance AEM.

4. Vérifiez les fichiers journaux et d’erreurs de votre serveur web et de Dispatcher.

   • Selon votre serveur web, vous devriez voir des messages tels que :
     • [Thu May 30 05:16:36 2002] [notice] Apache/2.0.50 (Unix) configured et
     • [Fri Jan 19 17:22:16 2001] [I] [19096] Dispatcher initialized (build XXXX)

5. Consulter le site web via le serveur web. Vérifiez que le contenu s’affiche selon les besoins.
   Par exemple, sur une installation locale où AEM s’exécute sur le port 4502 et le serveur web sur 80, accédez à la console Sites web à l’aide des éléments suivants :

   • https://localhost:4502/libs/wcm/core/content/siteadmin.html
   • https://localhost:80/libs/wcm/core/content/siteadmin.html
   • Les résultats devraient être identiques. Confirmez l’accès à d’autres pages avec le même mécanisme.

6. Vérifiez que le répertoire du cache est en cours de remplissage.

7. Pour vérifier que le cache est vidé correctement, activez une page.

8. Si tout fonctionne correctement, vous pouvez réduire la variable loglevel to 0.

Utilisation de plusieurs instances de Dispatcher

Dans les configurations complexes, vous pouvez utiliser plusieurs dispatchers. Par exemple, vous pouvez utiliser :

• une instance de Dispatcher pour publier un site web sur l’intranet ;
• un second dispatcher, sous une autre adresse et avec des paramètres de sécurité différents, pour publier le même contenu sur Internet.

Dans ce cas, veillez à ce que chaque demande ne passe par qu’un seul Dispatcher. Un Dispatcher ne gère pas les requêtes provenant d’un autre Dispatcher. Par conséquent, assurez-vous que les deux dispatchers accèdent directement au site web d’AEM.

Débogage

Lors de l’ajout de l’en-tête X-Dispatcher-Info à une requête, Dispatcher indique si la cible a été mise en cache, renvoyée de mise en cache ou si elle ne peut pas être mise en cache. L’en-tête de la réponse X-Cache-Info contient ces informations sous une forme lisible. Vous pouvez utiliser ces en-têtes de réponse pour déboguer des problèmes impliquant des réponses mises en cache par Dispatcher.

Cette fonctionnalité n’est pas activée par défaut. Par conséquent, pour l’en-tête de réponse X-Cache-Info pour être inclus, la ferme de serveurs doit contenir l’entrée suivante :

/info "1"

Par exemple,

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

En outre, la variable X-Dispatcher-Info L’en-tête n’a pas besoin d’une valeur, mais si vous utilisez curl pour les tests, vous devez fournir une valeur à envoyer à l’en-tête, par exemple :

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

Vous trouverez ci-dessous une liste contenant les en-têtes de réponse qui X-Dispatcher-Info renvoie :

• Mis en cache
  Le fichier cible est contenu dans le cache et Dispatcher a déterminé qu’il est valide pour la diffusion.
• Mise en cache
  Le fichier cible n’est pas contenu dans le cache et Dispatcher a déterminé qu’il est valide pour mettre en cache la sortie et la diffuser.
• mise en cache : le fichier statistique est plus récent
  Le fichier cible est contenu dans le cache, mais il est invalidé par un fichier de statistiques plus récent. Dispatcher supprime le fichier cible, le recrée à partir de la sortie et le diffuse.
• mise en cache impossible : pas de racine de document
  La configuration de la ferme de serveurs ne contient pas de racine de document (élément de configuration
  cache.docroot).
• mise en cache impossible : chemin du fichier de cache trop long
  Le fichier cible (concaténation de la racine du document et du fichier URL) dépasse le nom de fichier le plus long possible sur le système.
• mise en cache impossible : chemin du fichier temporaire trop long
  Le modèle de nom de fichier temporaire dépasse la longueur du plus long nom de fichier possible sur le système. Dispatcher crée d’abord un fichier temporaire avant de créer ou de remplacer le fichier mis en cache. Le nom de fichier temporaire est le nom du fichier cible avec les caractères _YYYYXXXXXX ajouté, où la variable Y et X sont remplacées pour créer un nom unique.
• mise en cache impossible : l’URL de la requête n’a pas d’extension
  L’URL de la demande n’a pas d’extension ou un chemin suit l’extension du fichier, par exemple : /test.html/a/path.
• mise en cache impossible : requête n’était pas un GET ou un HEAD
  La méthode HTTP n’est pas un GET ou un HEAD. Dispatcher suppose que la sortie contient des données dynamiques qui ne doivent pas être mises en cache.
• mise en cache impossible : la requête contenait une chaîne de requête
  La requête contenait une chaîne de requête. Dispatcher suppose que la sortie dépend de la chaîne de requête donnée et ne met donc pas en cache.
• mise en cache impossible : le gestionnaire de session ne s’est pas authentifié
  Le cache de la ferme de serveurs est régi par un gestionnaire de session (la configuration contient un nœud sessionmanagement) et la requête ne contenait pas les informations d’authentification appropriées.
• mise en cache impossible : la requête contient une autorisation
  La ferme de serveurs n’est pas autorisée à mettre en cache la sortie ( allowAuthorized 0) et la requête contient des informations d’authentification.
• mise en cache impossible : la cible est un répertoire
  Le fichier cible est un répertoire. Cet emplacement peut indiquer une erreur conceptuelle, où une URL et une sous-URL contiennent toutes deux une sortie pouvant être mise en cache. Par exemple, si une requête pour /test.html/a/file.ext s’affiche en premier et contient une sortie pouvant être mise en cache, Dispatcher ne peut pas mettre en cache la sortie d’une requête ultérieure vers /test.html.
• mise en cache impossible : l’URL de la requête est suivie d’une barre oblique
  L’URL de la requête est suivie d’une barre oblique.
• mise en cache impossible : l’URL de la requête ne figure pas dans les règles du cache
  Les règles de cache de la ferme de serveurs interdisent explicitement la mise en cache de la sortie de certaines URL de demande.
• mise en cache impossible : autorisation d’accès refusée
  Le vérificateur d’autorisation de la ferme de serveurs a refusé l’accès au fichier mis en cache.
• mise en cache impossible : session non valide
  Le cache de la ferme de serveurs est régi par un gestionnaire de session (la configuration contient un nœud sessionmanagement) et la session de l’utilisateur n’est pas ou plus valide.
• mise en cache impossible : La réponse contientno_cache
  Le serveur distant a renvoyé une
  Dispatcher: no_cache en-tête, interdisant à Dispatcher de mettre en cache la sortie.
• mise en cache impossible : la longueur du contenu de la réponse est zéro
  La longueur du contenu de la réponse est zéro ; Dispatcher ne crée pas de fichier de longueur nulle.

Ressources Business.Adobe.com

Ecommerce Integrations Content Insights Style System Personalized Experiences Content Intelligence Embedded Charts