Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=PZ5jpU9XIXI

Post Syndicated from corbet original https://lwn.net/Articles/946497/

OpenSSH 9.5 is out. Significant changes include a transport-level ping
mechanism and keystroke timing obfuscation:

This attempts to hide inter-keystroke timings by sending
interactive traffic at fixed intervals (default: every 20ms) when
there is only a small amount of data being sent. It also sends fake
“chaff” keystrokes for a random interval after the last real
keystroke. These are controlled by a new ssh_config
ObscureKeystrokeTiming keyword.

Post Syndicated from corbet original https://lwn.net/Articles/946496/

Security updates have been issued by Debian (glibc, postgresql-11, and thunderbird), Fedora (openmpi, pmix, prrte, and slurm), Gentoo (glibc and libvpx), Oracle (kernel), Red Hat (kernel), Slackware (libX11 and libXpm), SUSE (firefox, kernel, libeconf, libqb, libraw, libvpx, libX11, libXpm, mdadm, openssl-1_1, poppler, postfix, python311, rubygem-puma, runc, and vim), and Ubuntu (freerdp2, glibc, grub2-signed, grub2-unsigned, libx11, libxpm, linux-intel-iotg, linux-intel-iotg-5.15, linux-oracle, linux-oracle-5.15, and mozjs102).

Post Syndicated from Arielle Olache original http://blog.cloudflare.com/es-es/multihost-waiting-room-es-es/

Cloudflare Waiting Room protege los sitios contra las sobrecargas vinculadas a los picos de tráfico, colocando el exceso de visitantes en una sala de espera virtual, completamente personalizable, donde son admitidos dinámicamente a medida que se liberan plazas. En lugar de mostrar páginas de error o entregar páginas del sitio con un bajo rendimiento, Waiting Room permite a los clientes tomar el control de su experiencia de usuario final durante los picos de tráfico inmanejables.

Una decisión clave que toman los clientes al configurar una sala de espera es acerca de qué páginas protegerán. Hasta ahora, los clientes podían seleccionar una sola combinación de nombre de host y ruta de acceso para determinar las páginas cubiertas por una sala de espera. Hoy nos complace anunciar que Waiting Room ahora ofrece compatibilidad con varias combinaciones de nombres de host y rutas de acceso con una sola sala de espera, y ofrece así a los clientes más flexibilidad y una cobertura más amplia del sitio sin interrupciones de los flujos de los usuarios finales. Esta nueva funcionalidad está disponible para todos los clientes Enterprise con una versión Advanced de Waiting Room.

Colocación de un sitio en Waiting Room

Durante la implementación de una sala de espera, un proceso sencillo y que no requiere codificación, los clientes especifican una combinación de nombre de host y ruta de acceso para indicar las páginas cubiertas por una sala de espera determinada. Cuando un visitante del sitio realiza una solicitud preliminar a ese nombre de host y esa ruta de acceso o a cualquiera de sus rutas de acceso secundarias, recibe una cookie correspondiente a la sala de espera y entonces se admite en el sitio o bien, si el sitio está saturado, se coloca en una sala de espera.

El año pasado añadimos la funcionalidad Waiting Room Bypass Rules, que ofrece a los clientes muchas opciones para crear excepciones a esta cobertura de nombre de host y ruta de acceso. Esta funcionalidad ha desbloqueado funciones como la omisión de agente de usuario, el filtrado por geolocalización, las exclusiones de URL y la omisión administrativa de direcciones IP. Asimismo, ha mejorado la flexibilidad en lo referente a las páginas a las que se debe aplicar una sala de espera en el sitio de un cliente, al añadir la posibilidad de excluir URL, rutas de acceso y cadenas de consulta. Aunque esta actualización permitió una mayor especificidad acerca del tráfico que debe filtrar Waiting Room, no ofrecía la cobertura más amplia que aún necesitaban muchos clientes para proteger áreas más extensas de sus sitios con una sola sala de espera.

Por qué los clientes necesitaban una cobertura más amplia de Waiting Room

Analicemos algunos ejemplos sencillos pero adecuados de por qué esta opción de una cobertura más amplia era importante para nuestros clientes. Imagina que tienes una tienda en línea, example.com, y quieres asegurarte de que una sola sala de espera cubre todo el recorrido del cliente, desde la página inicial a la navegación por los productos, y finalmente a la validación del pedido. Muchos sitios utilizan rutas de acceso para definir estos pasos en el flujo: example.com/, example.com/shop/product1, example.com/checkout. Puesto que Waiting Room supone que existe un comodín implícito al final de la ruta de acceso configurada para una sala de espera, este caso de uso ya estaba cubierto para estos sitios. Por lo tanto, la configuración de una sala de espera en la dirección example.com/ permitirá cubrir todas las URL asociadas con cada uno de los pasos de este recorrido del cliente. En esta configuración, una vez que un visitante del sitio entraba en la sala de espera, no se volvía a poner en cola en ningún otro paso del flujo del usuario, ya que seguía utilizando la misma cookie correspondiente a la sala de espera, lo que indica a Waiting Room que se trata del mismo usuario en distintas URL.

No obstante, muchos sitios utilizan subdominios en lugar de, o además de, rutas de acceso para definir distintos pasos de este tipo de flujo de compra. Por ejemplo, la página de validación del pedido de muchos sitios estará en un subdominio distinto, por ejemplo, checkout.example.com. Hasta ahora, si un cliente tenía esta estructura de sitio y quería proteger todo su sitio con una sola sala de espera, necesitaba implementar una sala de espera en la dirección example.com/ y otra en la dirección checkout.example.com/. Esta opción no era idónea para muchos clientes, puesto que un visitante del sitio podía encontrarse puesto en cola en dos lugares distintos del mismo recorrido de cliente. Esto se debe a que la sala de espera en la dirección checkout.example.com/ contabilizaría el mismo visitante como un usuario distinto que el de la sala de espera que cubre el sitio example.com/.

Dicho esto, en algunos casos es recomendable separar las salas de espera que cubren un solo sitio. Por ejemplo, un sitio web de venta de entradas podría implementar una sala de espera en su dominio raíz (example.com) y distintas salas de espera con pre-colas de espera en páginas dedicadas a eventos específicos (example.com/popular_artist_tour). La sala de espera definida en la página example.com/ garantiza que el punto de acceso principal al sitio no se sobrecargue y deje de estar accesible al abrir la venta de entradas para un evento específico. La sala de espera definida en la página dedicada al evento específico garantiza que el tráfico correspondiente a un evento determinado se pueda empezar a poner en cola de espera antes del evento sin afectar al tráfico que se dirige a otros lugares del sitio.

En definitiva, independientemente de si un cliente desea tener una o varias salas de espera para proteger su sitio, queríamos ofrecer a nuestros clientes la flexibilidad de implementar Waiting Room de la forma que se ajustara mejor a sus casos de uso y a su estructura del sitio. Nos complace anunciar que Waiting Room ahora admite la cobertura de varios nombres de host y rutas de acceso con una sola sala de espera.

Cómo empezar a utilizar la cobertura de varios hosts y rutas de acceso

Ahora los clientes pueden configurar una sala de espera en varias combinaciones de nombres de host y ruta (o rutas) de acceso correspondientes a la misma zona. Para ello, ve a Tráfico > Waiting Room y selecciona Create (Crear). El nombre de tu dominio ya estará rellenado. Para añadir reglas adicionales a la configuración de tu sala de espera, selecciona Add Hostname and Path (Añadir nombre de host y ruta de acceso). A continuación, puedes especificar otro nombre de host y ruta de acceso que desees que cubra la misma sala de espera. Recuerda que hay un comodín implícito al final de cada ruta de acceso. Por lo tanto, es innecesario crear una sala de espera para cada URL que desees que cubra tu sala de espera. Crea solo rutas de acceso adicionales para las URL que no estén cubiertas por las combinaciones de nombres de host y rutas de acceso que ya hayas especificado.

Al implementar una sala de espera que cubra varias combinaciones de nombres de host y rutas de acceso, debes crear un nombre de cookie exclusivo para esa sala de espera (más información más adelante). A continuación, continúa con el mismo flujo de trabajo de la forma habitual para implementar tu sala de espera.

Implementación de una sala de espera multilingüe

Los clientes nos han solicitado a menudo la posibilidad de cubrir un sitio multilingüe con una sola sala de espera, y ofrecer así texto específico para cada idioma al mismo tiempo que se contabiliza todo el tráfico del sitio en los mismos límites de la sala de espera. Hay varios métodos para estructurar un sitio a fin de definir las distintas opciones lingüísticas. Sin embargo, los dos más habituales son por subdominio o por ruta de acceso. Para un sitio que utilice la definición por ruta de acceso, podría presentarse así: example.com/en y example.com/es para inglés y español, respectivamente. Para un sitio que utilice la definición por subdominio, podría presentarse así: en.example.com/ y es.example.com/. Antes de que Waiting Room ofreciera la cobertura de varios hosts, la variación por subdominio no podría haber estado cubierta por una única sala de espera.

Las opciones de configuración existentes de Waiting Room ya admitían la variación por ruta de acceso. Sin embargo, esto solo era cierto si el cliente quería filtrar todo el sitio, lo que podía hacer definiendo la sala de espera en la página example.com/. Muchos clientes de comercio electrónico han solicitado la posibilidad de filtrar distintas páginas de productos con alta demanda que ofrecen el mismo producto pero con distintas opciones de idioma. Por ejemplo, considera example.com/en/product_123 y example.com/es/product_123, donde el cliente desea utilizar la misma sala de espera y aplicar los mismos límites de tráfico para cubrir ambas URL. Hasta ahora, esto no habría sido posible sin alguna compleja lógica de reglas de omisión.

Ahora, los clientes pueden implementar una sala de espera que se ajuste al método elegido de estructuración de un sitio multilingüe, ya sea por subdominio o por ruta de acceso. Para terminar, solo debes configurar tu sala de espera para que entregue distintos idiomas cuando un usuario se ponga en cola en una sala de espera. Para ello, puedes crear una plantilla que lea la URL a fin de determinar los parámetros de idioma y definir las traducciones adecuadas para cada idioma en la plantilla.

A continuación se muestra un ejemplo de una plantilla que determina los parámetros de idioma de la ruta de acceso de la URL, y que presenta el texto traducido:

<!DOCTYPE html>
<html>
  <head>
    <title>Waiting Room powered by Cloudflare</title>
  </head>
  <body>
    <section>
      <h1 id="inline-msg">
        You are now in line.
      </h1>
      <h1 id="patience-msg">
        Thank you for your patience.
      </h1>
    </section>
    <h2 id="waitTime"></h2>

    <script>
      var locale = location.pathname.split("/")[1] || "en";
      var translations = {
        "en": {
          "waittime_60_less": "Your estimated wait time is {{waitTime}} minute.",
          "waittime_60_greater": "Your estimated wait time is {{waitTimeHours}} hours and {{waitTimeHourMinutes}} minutes.",
          "inline-msg": "You are now in line.",
          "patience-msg": "Thank you for your patience.",
        },
        "es": {
          "waittime_60_less": "El tiempo de espera estimado es {{waitTime}} minuto.",
          "waittime_60_greater": "El tiempo de espera estimado es {{waitTimeHours}} de horas y {{waitTimeHourMinutes}} minutos.",
          "inline-msg": "Ahora se encuentra en la fila de espera previa.",
          "patience-msg": "Gracias por su paciencia.",
        }
      };

      {{#waitTimeKnown}}
      var minutes = parseInt( {{waitTime}} , 10);
      var time = document.getElementById('waitTime');

      if ( minutes < 61) {
        time.innerText = translations[locale]["waittime_60_less"]
      } else {
        time.innerText = translations[locale]["waittime_60_greater"]
      }
      {{/waitTimeKnown}}

      // translate template text for each of the elements with “id” suffixed with “msg”
      for (const msg of ["inline-msg", "patience-msg"]) {
        const el = document.getElementById(msg);
        if (el == null) continue;
        el.innerText = translations[locale][msg];
      }
    </script>
  </body>
</html>

La plantilla funciona de la forma siguiente: si un sitio distingue entre distintos parámetros de idioma con distintas rutas de acceso, como /en/product_123 o /es/product_123 en el cuerpo <script /> después de representar la página, el parámetro de idioma se extrae de location.pathname mediante locale = location.pathname.split(“/”)[1]. Si no se ha especificado ningún parámetro de idioma en el objeto `translations`, por defecto utilizamos “en”. Por ejemplo, si un usuario visita example.com/product_123, por defecto se representa la plantilla con el texto en inglés.

De la misma forma, para admitir una sala de espera multilingüe correspondiente a sitios que definen la estructura del sitio por subdominio, únicamente deberías actualizar cómo extraer el parámetro de idioma de la URL. En lugar de comprobar `pathname`, comprobamos la propiedad `hostname` del objeto `window.location` como `locale = location.hostname.split(“.”)[0]`, nuestra estructura del sitio será la siguiente: en.example.com, es.example.com.

El código anterior es un ejemplo simplificado de las plantillas iniciales que hemos añadido a nuestra documentación para desarrolladores. Las hemos incluido para que te sea más fácil empezar a utilizar una sala de espera multilingüe. Puedes descargar estas plantillas y editarlas para que su aspecto se ajuste a tu sitio y a las opciones de idioma que este ofrece.

Estas plantillas se pueden ampliar para incluir otros idiomas añadiendo las traducciones al objeto `translations` para cada uno de los idiomas. De esta forma, una única plantilla puede entregar varios idiomas, en función del parámetro de idioma que se aplique al sitio, ya sea por subdominio o por ruta de acceso.

Cómo gestionamos las cookies con una sala de espera que cubre varios nombres de host y rutas de acceso

La sala de espera asigna una cookie __cfwaitingroom a cada usuario para gestionar el estado del usuario, la cual determina la posición del usuario en la cola de espera, así como otras propiedades necesarias para decidir acerca de la colocación en cola de espera vinculadas al usuario. Tradicionalmente, para una configuración de un único nombre de host y ruta de acceso, era muy sencillo definir simplemente la cookie como __cfwaitingroom=[cookie-value]; Domain=example.com; Path=/es/product_123. Esto garantizaba que cuando se renovará la página nos enviaría la misma cookie de Waiting Room para que la analizáramos y actualizáramos. Sin embargo, dejó de ser sencillo cuando quisimos compartir la misma cookie en distintas combinaciones de subdominios o rutas de acceso, por ejemplo, en example.com/en/product_123.

Métodos para establecer varias cookies

Consideramos y evaluamos dos métodos para permitir el uso compartido de la cookie para la misma sala de espera.

El primer método que consideramos era emitir varios encabezados Set-Cookie en la respuesta HTTP. En el ejemplo multilingüe anterior, por ejemplo, podríamos añadir lo siguiente en el encabezado de la respuesta:

Set-Cookie: __cfwaitingroom=[cookie-value]…Domain=example.com; Path=/en/product_123 …
Set-Cookie: __cfwaitingroom=[cookie-value]...Domain=example.com; Path=/es/product_123 …

Este método nos permitiría gestionar los varios nombres de host y rutas de acceso para la misma sala de espera. Sin embargo, no se presenta como una solución escalable. La especificación RFC6265 no define ningún límite estricto, pero los navegadores aplican sus propios límites según cada implementación. Por ejemplo, Chrome permite que el encabezado de la respuesta tenga hasta 256 Kbytes antes de devolver un error ERR_RESPONSE_HEADERS_TOO_BIG para la transacción. Además, en este caso, el encabezado de la respuesta crecería proporcionalmente al número de combinaciones de nombres de host y rutas de acceso exclusivas, y estaríamos repitiendo de forma redundante el mismo valor de cookie N número de veces (donde N es el número de rutas adicionales). Aunque este enfoque nos habría permitido gestionar eficazmente una lista limitada de combinaciones de nombres de host y rutas de acceso que sería necesario establecer, no era idóneo para aquello casos donde se espera un número mayor de rutas para un sitio determinado.

El segundo enfoque que hemos considerado, y con el que decidimos seguir adelante, consistía en establecer la cookie en el dominio raíz (o el subdominio más habitual). En otras palabras, buscaríamos el subdominio más habitual en la lista de rutas y lo utilizaríamos como dominio. De la misma forma, en el caso de las rutas, esto implicaría determinar el prefijo menos habitual de la lista de rutas y utilizarlo como el valor que se debe establecer en el atributo path. Por ejemplo, considera una sala de espera con las siguientes dos rutas configuradas, a.example.com/shoes/product_123 y b.example.com/shoes/product_456.

Para determinar el dominio que se establecería para la cookie, podemos observar que example.com es el subdominio más habitual en la lista de dominios. Al aplicar el algoritmo de subdominio más habitual, obtendríamos example.com como subdominio. Al aplicar el algoritmo de prefijo menos habitual en el conjunto de rutas de acceso, /shoes/product_123 y /shoes/product_456, obtendríamos /shoes como ruta de acceso. Por lo tanto, el encabezado set-cookie sería el siguiente:

Set-Cookie: … __cfwaitingroom=[cookie-value]; Domain=example.com; Path=/shoes …

Ahora, cuando un visitante accede a cualquiera de las páginas cubiertas por esta sala de espera, podemos garantizar que Waiting Room recibe la cookie adecuada y que solo se habrá incluido Set-Cookie en el encabezado de la respuesta.

Sin embargo, aún no hemos terminado. Aunque podemos identificar el subdominio habitual (o dominio raíz) y el prefijo de ruta de acceso común, aún tendríamos un problema si las rutas desde una sala de espera se solaparan con las de otra sala de espera. Por ejemplo, supongamos que configuramos dos salas de espera para el mismo sitio donde vendemos nuestro calzado especial:

Sala de espera A
    a.example.com/shoes/product_123
    b.example.com/shoes/product_456

Sala de espera B
    c.example.com/shoes/product_789
    d.example.com/shoes/product_012

Si aplicamos el mismo algoritmo tal como hemos descrito anteriormente, se establecerían las mismas propiedades de dominio y ruta de acceso para ambas cookies. Para la sala de espera A, el dominio sería example.com y la ruta de acceso sería /shoes. De la misma forma, para la sala de espera B, el subdominio más habitual también sería example.com y el prefijo de ruta de acceso menos habitual sería be /shoes. Esto nos evitaría eficazmente distinguir ambas cookies y dirigiría al visitante a la sala de espera adecuada. Para resolver el problema del solapamiento de los nombres de cookie, hemos añadido el requisito de definir un sufijo personalizado exclusivo para la zona del cliente. Por este motivo, es necesario proporcionar un sufijo de cookie personalizado al configurar una sala de espera que cubra varios nombres de host y rutas de acceso. Por lo tanto, si se ha asignado a la sala de espera A el sufijo de cookie “a” y a la sala de espera B el sufijo de cookie “b”, las dos definiciones de Set-Cookie serán las siguientes:

Sala de espera A

Set-Cookie: __cfwaitingroom_a=[cookie-value]; Domain=example.com; Path=/shoes

Sala de espera B

Set-Cookie: __cfwaitingroom_b=[cookie-value]; Domain=example.com; Path=/shoes

Cuando un visitante envía una solicitud a una página donde hay configuradas dos salas de espera distintas, Waiting Room puede distinguir y seleccionar la cookie correspondiente a esa solicitud específica y utilizarla para determinar qué ajustes de sala de espera son aplicables a ese usuario, en función de dónde se encuentre en el sitio.

Con la adición de la cobertura de varios host y rutas de acceso a Waiting Room, nos complace ofrecerte opciones para que puedas incorporar Waiting Room en tu sitio con mayor flexibilidad, proporcionando así a tus visitantes la mejor experiencia posible, al mismo tiempo que proteges tu sitio durante periodos de mucho tráfico. Asegúrate de que tu sitio esté siempre protegido contra los picos de tráfico. Prueba ya Waiting Room o ponte en contacto con nosotros para saber más sobre la versión Advanced de Waiting Room.

Post Syndicated from Arielle Olache original http://blog.cloudflare.com/fr-fr/multihost-waiting-room-fr-fr/

Cloudflare Waiting Room protège les sites contre les surcharges liées aux pics de trafic en transférant l’excédent de visiteurs vers une salle d’attente virtuelle, entièrement personnalisable, dans laquelle les visiteurs sont admis dynamiquement, au fur et à mesure que des places se libèrent. Au lieu d’afficher des pages d’erreur ou de proposer une expérience insatisfaisante de l’affichage des pages du site, Waiting Room permet aux clients de prendre le contrôle de l’expérience de leurs utilisateurs finaux pendant les pics de trafic ingérables.

L’une des principales décisions que prennent les clients lors de la configuration d’une salle d’attente consiste à sélectionner les pages que protégera celle-ci. Jusqu’à présent, les clients pouvaient sélectionner un nom d’hôte et un chemin d’accès lors de la désignation des pages protégées par une instance de Waiting Room. Aujourd’hui, nous sommes ravis d’annoncer que Waiting Room propose désormais la prise en charge de combinaisons de noms d’hôtes et de chemins d’accès multiples pour une salle d’attente unique, offrant ainsi aux clients davantage de flexibilité et une prise en charge plus étendue des sites, sans interruption des flux des utilisateurs finaux.Cette nouvelle fonctionnalité est accessible à tous les clients Enterprise ayant préacheté Waiting Room.

Ajout d’un site dans Waiting Room

Le déploiement d’une salle d’attente est une procédure simple et sans codage, durant laquelle les clients spécifient une combinaison de nom d’hôte et de chemin d’accès afin de désigner les pages prises en charge par une salle d’attente particulière. Lorsqu’un visiteur du site transmet une requête préliminaire à ce nom d’hôte et ce chemin d’accès ou l’un de ses sous-chemins, il reçoit un cookie correspondant à la salle d’attente et est ensuite admis sur le site ou transféré vers une salle d’attente, si le site est saturé.

L’année dernière, nous avons ajouté la fonctionnalité Waiting Room Bypass Rules, qui offre aux clients de nombreuses options permettant de créer des exceptions à cette prise en charge des noms d’hôtes et des chemins d’accès. Cette fonctionnalité a débloqué des capacités telles que le contournement d’agent utilisateur, le ciblage par géolocalisation, les exclusions d’URL et le contournement d’adresses IP d’administration. Elle a également offert davantage de flexibilité au regard de la prise en charge par Waiting Room des pages du site d’un client en ajoutant la possibilité d’exclure des URL, des chemins d’accès et des chaînes de requête. Si cette mise à jour a permis de mieux définir le trafic devant être filtré par Waiting Room, elle n’offrait néanmoins pas la prise en charge étendue que recherchaient encore de nombreux clients pour protéger de plus vastes pans de leurs sites avec une salle d’attente unique.

Pourquoi les clients avaient besoin d’une prise en charge plus étendue par Waiting Room

Examinons quelques exemples simples, mais pertinents, des raisons pour lesquelles cette option de prise en charge étendue était importante pour nos clients. Imaginons que vous ayez une boutique en ligne, example.com, et que vous souhaitiez vous assurer qu’une salle d’attente unique couvre l’ensemble du parcours du client – de la page d’accueil jusqu’à la navigation sur les produits, puis au paiement. De nombreux sites emploient les chemins pour délimiter ces étapes au sein du flux : example.com/, example.com/shop/product1, example.com/payment. Puisque Waiting Room suppose qu’un caractère générique implicite est présent à la fin du chemin d’accès configuré pour une salle d’attente, ce scénario d’utilisation était déjà pris en charge pour ces sites. Ainsi, la configuration d’une salle d’attente à l’adresse example.com/ permettrait de couvrir toutes les URL associées à chaque étape du parcours du client. Dans cette configuration, lorsqu’un visiteur consultant le site avait traversé la salle d’attente, il ne réintégrait pas la file d’attente à une étape ultérieure de son parcours d’utilisateur, car il disposait toujours du même cookie correspondant à la salle d’attente, qui indique à Waiting Room qu’il s’agit d’un même utilisateur parcourant les différentes URL.

Cependant, de nombreux sites utilisent des sous-domaines à la place des chemins d’accès, ou conjointement à ceux-ci, pour délimiter les différentes étapes de ce type de parcours d’achat. Par exemple, la page de paiement de nombreux sites se trouve sur un sous-domaine différent, comme payment.example.com. Jusqu’à présent, si un client disposait de cette structure de site et souhaitait protéger l’ensemble de son site avec une salle d’attente unique, il devait configurer une première salle d’attente à l’adresse example.com/, et une deuxième salle d’attente à l’adresse payment.example.com/. Cette option était peu pratique pour de nombreux clients, car un visiteur pouvait se retrouver ajouté à une file d’attente à deux endroits différents du même parcours client. En effet, la salle d’attente de payment.example.com/ compterait le même visiteur comme un autre utilisateur de celui de la salle d’attente couvrant example.com/.

Cela étant dit, dans certains cas, il est judicieux de séparer les salles d’attente couvrant un même site. Par exemple, un site web de billetterie pourrait déployer une salle d’attente sur son domaine racine (example.com), puis déployer des salles d’attente distinctes avec des pré-files d’attente sur les pages consacrées à des événements spécifiques (example.com/popular_artist_tour). La salle d’attente de la page example.com/ permet d’éviter que le principal point d’accès au site ne soit submergé par les requêtes et que le site devienne inaccessible lors de l’ouverture de la vente de billets pour un événement donné. La salle d’attente placée sur la page de l’événement spécifique assure que le trafic correspondant à un événement particulier puisse être mis en file d’attente avant l’événement, sans toutefois affecter le trafic affluant vers d’autres parties du site.

En fin de compte, peu importe qu’un client souhaite déployer une ou plusieurs salles d’attente pour protéger son site : nous souhaitions offrir à chaque client la possibilité de déployer Waiting Room de la manière la plus adaptée à ses scénarios d’utilisation et sa structure de site. Nous sommes ravis d’annoncer que Waiting Room offre désormais la prise en charge de noms d’hôtes et de chemins d’accès multiples dans une salle d’attente unique !

Découvrir la prise en charge d’hôtes et de chemins d’accès multiples

Les clients peuvent désormais configurer une salle d’attente avec plusieurs combinaisons de noms d’hôtes et de chemins (ou d’itinéraires) appartenant à une même zone. Pour cela, accédez à Trafic > Waiting Room, puis sélectionnez Create (Créer). Le nom de votre domaine sera déjà renseigné. Pour ajouter des itinéraires supplémentaires à la configuration de votre salle d’attente, sélectionnez Add Hostname (Ajouter un nom d’hôte), puis Path (Chemin d’accès). Vous pouvez ensuite saisir un autre nom d’hôte et un autre chemin d’accès qui seront couverts par la même salle d’attente. N’oubliez pas qu’un caractère générique implicite est inclus après chaque chemin d’accès ; il n’est donc pas nécessaire de créer une salle d’attente pour chaque URL que vous souhaitez couvrir. Créez uniquement des itinéraires supplémentaires pour les URL qui ne seraient pas couvertes par les autres combinaisons de noms d’hôtes et de chemins d’accès que vous avez déjà spécifiées.

Lorsque vous déployez une salle d’attente couvrant plusieurs combinaisons de noms d’hôtes et de chemins d’accès, vous devez créer un nom de cookie unique pour cette salle d’attente (nous y reviendrons plus tard). Ensuite, appliquez le même flux de travail que d’habitude pour déployer votre salle d’attente.

Déployer une salle d’attente multilingue

Une demande fréquemment formulée par nos clients était la possibilité de couvrir un site multilingue avec une salle d’attente unique, en proposant des textes différents dans chaque langue, tout en comptabilisant l’ensemble du trafic du site dans les limites de la même salle d’attente. Il existe plusieurs façons de structurer un site pour à délimiter les différentes options linguistiques ; toutefois, les deux approches les plus courantes sont la délimitation par sous-domaine ou par chemin d’accès. Pour un site qui utilise la délimitation par chemin d’accès, cela pourrait se présenter ainsi : example.com/en et example.com/es pour l’anglais et l’espagnol, respectivement. Pour un site utilisant la délimitation par sous-domaine, la configuration pourrait être la suivante : en.example.com/ et es.example.com/. Avant la prise en charge d’hôtes multiples par Waiting Room, la variation des sous-domaines n’aurait pas pu être couverte par une salle d’attente unique.

Les options de configuration existantes de Waiting Room prenaient déjà en charge les variations de chemin d’accès. Cependant, cela n’était vrai que si le client souhaitait couvrir l’ensemble du site, ce qui était réalisable en en plaçant la salle d’attente à l’adresse example.com/. De nombreux clients dans le secteur de l’e-commerce ont demandé la possibilité de couvrir différentes pages de produits très demandées, proposant le même produit, avec des options linguistiques différentes. Par exemple, prenons le cas de example.com/en/product_123 et de example.com/es/product_123. Pour ces pages, le client souhaite couvrir les deux URL avec la même salle d’attente et des limites de trafic identiques. Jusqu’à présent, cela n’aurait pas été possible sans configurer une logique complexe basée sur des règles de contournement.

Désormais, toutefois, les clients peuvent déployer une salle d’attente couvrant, au choix, l’approche basée sur les sous-domaines ou les chemins d’accès pour structurer un site multilingue. L’unique étape restante consiste à configurer votre salle d’attente afin qu’elle puisse servir différentes langues lorsqu’un utilisateur est transféré vers une salle d’attente. Pour cela, vous pouvez développer un modèle lisant l’URL afin de déterminer les paramètres régionaux, puis définir les traductions appropriées pour chaque langue dans le modèle.

Voici un exemple de modèle qui détermine les paramètres régionaux à partir du chemin d’accès de l’URL, puis affiche le texte traduit :

<!DOCTYPE html>
<html>
  <head>
    <title>Waiting Room powered by Cloudflare</title>
  </head>
  <body>
    <section>
      <h1 id="inline-msg">
        You are now in line.
      </h1>
      <h1 id="patience-msg">
        Thank you for your patience.
      </h1>
    </section>
    <h2 id="waitTime"></h2>

    <script>
      var locale = location.pathname.split("/")[1] || "en";
      var translations = {
        "en": {
          "waittime_60_less": "Your estimated wait time is {{waitTime}} minute.",
          "waittime_60_greater": "Your estimated wait time is {{waitTimeHours}} hours and {{waitTimeHourMinutes}} minutes.",
          "inline-msg": "You are now in line.",
          "patience-msg": "Thank you for your patience.",
        },
        "es": {
          "waittime_60_less": "El tiempo de espera estimado es {{waitTime}} minuto.",
          "waittime_60_greater": "El tiempo de espera estimado es {{waitTimeHours}} de horas y {{waitTimeHourMinutes}} minutos.",
          "inline-msg": "Ahora se encuentra en la fila de espera previa.",
          "patience-msg": "Gracias por su paciencia.",
        }
      };

      {{#waitTimeKnown}}
      var minutes = parseInt( {{waitTime}} , 10);
      var time = document.getElementById('waitTime');

      if ( minutes < 61) {
        time.innerText = translations[locale]["waittime_60_less"]
      } else {
        time.innerText = translations[locale]["waittime_60_greater"]
      }
      {{/waitTimeKnown}}

      // translate template text for each of the elements with “id” suffixed with “msg”
      for (const msg of ["inline-msg", "patience-msg"]) {
        const el = document.getElementById(msg);
        if (el == null) continue;
        el.innerText = translations[locale][msg];
      }
    </script>
  </body>
</html>

Voici comment fonctionne le modèle : puisqu’un site distingue différents paramètres régionaux avec différents chemins tels que `/en/product_123` ou `/es/product_123` dans le corps `<script />` après avoir effectué le rendu de la page, le paramètre régional est extrait de `location.pathname` via `locale = location.pathname.split(“/”)[1]`. Si aucune langue n’est spécifiée dans l’objet `translations`, la valeur par défaut est « en ». Par exemple, si un utilisateur consulte le site example.com/product_123, par défaut, le site affiche le rendu du modèle de texte anglais.

De même, pour prendre en charge une salle d’attente multilingue pour les sites délimitant la structure du site par sous-domaine, il suffirait de modifier la manière dont le paramètre régional est extrait de l’URL. Au lieu d’examiner `pathname`, nous examinons la propriété `hostname` de l’objet `window.location` (par exemple, `locale = location.hostname.split(“.”)[0]`),étant donné que la structure de notre site est la suivante : en.example.com, es.example.com.

Le code présenté ci-dessus est un exemple réduit des modèles de démarrage que nous avons ajoutés à notre documentation pour développeurs afin de faciliter la configuration d’une salle d’attente multilingue. Vous pouvez télécharger ces modèles et les modifier afin d’adapter leur apparence et leur fonctionnalité à votre site et aux options linguistiques proposées par celui-ci.

Ces modèles peuvent être étendus pour inclure d’autres langues en ajoutant des traductions à l’objet `translations` pour chacun des paramètres régionaux. Un modèle unique peut ainsi servir plusieurs langues en fonction des paramètres régionaux définis pour le site, qu’il s’agisse d’un sous-domaine ou d’un chemin d’accès.

Comment nous gérons les cookies avec une salle d’attente couvrant plusieurs noms d’hôtes et chemins d’accès

La salle d’attente alloue à chaque utilisateur un cookie `__cfwaitingroom` permettant de gérer son état ; ce cookie détermine la position de l’utilisateur dans la file d’attente, ainsi que d’autres propriétés nécessaires pour prendre les décisions de mise en file d’attente. Traditionnellement, pour une configuration comportant un nom d’hôte et un chemin d’accès uniques, il était extrêmement simple de définir le cookie comme ceci : `__cfwaitingroom=[cookie-value]; Domain=example.com; Path=/es/product_123`. Ainsi, lorsque la page était actualisée, elle transmettait le même cookie Waiting Room, nous permettant de l’examiner et de le mettre à jour. Toutefois, cette procédure devenait beaucoup moins simple lorsque nous voulions partager le même cookie pour différentes combinaisons de sous-domaines ou de chemins d’accès, par exemple, `example.com/en/product_123`.

Approches de la configuration de plusieurs cookies

Nous avons envisagé et évalué deux approches permettant le partage du cookie pour une même salle d’attente.

La première approche que nous avons envisagée consistait à insérer plusieurs en-têtes `Set-Cookie` dans la réponse HTTP. Par exemple, dans l’exemple multilingue ci-dessus, nous pourrions ajouter les indications suivantes dans l’en-tête de la réponse :

Set-Cookie: __cfwaitingroom=[cookie-value]…Domain=example.com; Path=/en/product_123 …
Set-Cookie: __cfwaitingroom=[cookie-value]...Domain=example.com; Path=/es/product_123 …

Cette approche nous permettrait de gérer plusieurs noms d’hôtes et chemins d’accès pour une même salle d’attente. Cependant, elle ne constitue pas une solution très évolutive. Conformément à RFC6265, aucune limite stricte n’est définie dans la spécification ; les navigateurs comportent des limites particulières, spécifiques à l’implémentation. Par exemple, Chrome accepte une taille d’en-tête de 256 K octets avant de renvoyer l’erreur ERR_RESPONSE_HEADERS_TOO_BIG pour la transaction. Par ailleurs, dans ce cas, la taille de l’en-tête de réponse augmenterait proportionnellement au nombre de combinaisons uniques de noms d’hôtes et de chemins d’accès et, de manière redondante, nous répéterions N fois (où N représente le nombre d’itinéraires supplémentaires) la même valeur de cookie. Cette approche nous aurait permis de gérer efficacement une liste restreinte de combinaisons de noms d’hôtes et de chemins d’accès à définir ; toutefois, elle n’était pas idéale dans les situations où un site particulier comportait plus qu’un nombre limité d’itinéraires.

La deuxième approche à laquelle nous avons réfléchi, et que nous avons choisie, consistait à placer le cookie sur le domaine racine (ou le sous-domaine le plus courant). En d’autres termes, nous déterminons le sous-domaine le plus courant à partir de la liste des itinéraires, et nous l’utilisons comme domaine. De manière similaire, pour les chemins d’accès, il s’agirait de déterminer le préfixe le moins commun à partir de la liste des chemins d’accès et de l’utiliser comme valeur à définir par l’attribut de chemin d’accès. Prenons l’exemple d’une salle d’attente pour laquelle les deux itinéraires suivants ont été configurés : a.example.com/shoes/product_123 et b.example.com/shoes/product_456.

Pour déterminer le domaine défini pour le cookie, nous voyons que `example.com` est le sous-domaine le plus courant parmi la liste des domaines. L’application de l’algorithme du sous-domaine le plus courant renverrait le domaine `example.com` ; en revanche, l’application de l’algorithme du préfixe le moins courant à l’ensemble de chemins d’accès `/shoes/product_123` et `/shoes/product_456` renverrait le chemin d’accès `/shoes`. Par conséquent, l’en-tête Set-Cookie serait le suivant :

Set-Cookie: … __cfwaitingroom=[cookie-value]; Domain=example.com; Path=/shoes …

Désormais, lorsqu’un visiteur accède à l’une des pages couvertes par cette salle d’attente, nous pouvons garantir que Waiting Room reçoit le bon cookie et que l’en-tête de la réponse contiendra uniquement `Set-Cookie`.

Cependant, la configuration n’est pas encore terminée. Bien que nous soyons en mesure d’identifier le sous-domaine commun (ou domaine racine) et le préfixe de chemin d’accès commun, un problème demeurerait si les itinéraires correspondant à une salle d’attente étaient identiques à ceux définis pour une autre salle d’attente. Par exemple, supposons que nous configurions deux salles d’attente pour un même site, sur lequel nous vendons nos chaussures spéciales :

Salle d’attente A
    a.example.com/shoes/product_123
    b.example.com/shoes/product_456

Salle d’attente B
    c.example.com/shoes/product_789
    d.example.com/shoes/product_012

Si nous appliquons le même algorithme que celui décrit ci-dessus, nous obtiendrons les mêmes propriétés de domaine et de chemin d’accès pour les deux cookies. Pour la salle d’attente A, le domaine serait `example.com` et le chemin d’accès serait `/shoes`. De même, pour la salle d’attente B, le sous-domaine le plus courant serait également example.com, et le préfixe de chemin d’accès le moins courant serait `/shoes`. Concrètement, ceci nous empêcherait de distinguer les deux cookies et de rediriger le visiteur vers la salle d’attente correcte. Afin de résoudre le problème du chevauchement des noms de cookies, nous avons introduit la nécessité de définir un suffixe personnalisé unique pour la zone du client. C’est pourquoi il est nécessaire de spécifier un suffixe de cookie personnalisé lors de la configuration d’une salle d’attente couvrant plusieurs noms d’hôtes ou chemins d’accès. Par conséquent, si la salle d’attente A reçoit le suffixe de cookie « a » et la salle d’attente B le suffixe de cookie « b », les deux définitions de `Set-Cookie` se présenteront comme ceci :

Salle d’attente A

Set-Cookie: __cfwaitingroom_a=[cookie-value]; Domain=example.com; Path=/shoes

Salle d’attente B

Set-Cookie: __cfwaitingroom_b=[cookie-value]; Domain=example.com; Path=/shoes

Lorsqu’un visiteur transmet une requête à une page pour laquelle ces deux salles d’attente différentes sont configurées, Waiting Room peut distinguer et sélectionner le cookie correspondant à la requête transmise et l’utiliser pour déterminer les paramètres de la salle d’attente applicables à cet utilisateur en fonction de l’endroit où il se trouve sur le site.

Avec l’ajout de la prise en charge de plusieurs hôtes et chemins d’accès par Waiting Room, nous sommes ravis de proposer des options plus flexibles pour l’incorporation de Waiting Room sur votre site, et ainsi, d’offrir à vos visiteurs la meilleure expérience possible, tout en protégeant votre site pendant les périodes d’affluence. Assurez-vous que votre site est toujours protégé contre les pics de trafic. Essayez dès aujourd’hui Waiting Room ou contactez-nous pour en savoir plus sur la solution Advanced Waiting Room.

Post Syndicated from Arielle Olache original http://blog.cloudflare.com/ja-jp/multihost-waiting-room-ja-jp/

Cloudflare Waiting Roomは、完全にカスタマイズ可能な仮想待機室に過剰なウェブ訪問者を配置し、空き枠ができると動的にこれを受け入れることにより、急激なトラフィック急増からサイトを保護します。Waiting Roomにより、管理しきれないトラフィック急増時にエラーページを表示したりパフォーマンスの低いサイトページを配信したりするのではなく、エンドユーザーエクスペリエンスをコントロールできるようにします。

待機室を設定する際、保護の対象となるページの決定が重要になります。これまでは、ホスト名とパスの組み合わせを1つ選び、待機室の対象となるページを決めることができました。今日、Waiting Roomsでは、単一の待機室で複数のホスト名とパスの組み合わせに対応できるようになりました。これにより、お客様にはより多くの柔軟性がもたらされ、エンドユーザーのフローを中断することなく、より広範なサイトカバレッジを提供できるようになりました。この新機能は、「Waiting Rooms」のアドバンスをご利用のすべてのEnterprise契約のお客様にご利用いただけます。

Waiting Roomsのサイトでの設置

シンプルかつコーディング不要の待機室のデプロイプロセスでは、ホスト名とパスの組み合わせを指定し、特定の待機室がカバーするページを指定します。Web訪問者がそのホスト名とパス、またはそのサブパスに予備リクエストを行うと、待機室クッキーが発行され、サイトへの入場が許可されるか、もしくはサイトの容量が足りない場合、待機室に導きます。

昨年、当社は Waiting Roomのバイパスルール機能を追加し、ホスト名とパスカバレッジの例外を設けるための多くの選択肢をお客様に提供しました。これにより、ユーザーエージェントバイパス、ジオターゲティング、URL除外、管理用IPバイパスなどの機能が活用できるようになりました。また、URL、パス、クエリ文字列を除外する機能を追加することで、顧客サイト上で待機室を適用するページの設定の柔軟性を高めることとなりました。このアップデートにより、Waiting Roomによってゲートされるべきトラフィックをより具体化できるようになった一方、カバレッジは狭いままで多くの顧客が単一の待機室でサイトの大部分を保護することはできませんでした。

顧客がよりカバレッジのWaiting Roomsを必要とした理由

幅広いカバレッジを持つ製品機能が顧客にとって重要であった理由について、簡単ではあるもののインパクトのある例をいくつか挙げてみます。example.comというオンラインストアがあるとします。単一の待機室で、ホームページから商品閲覧、チェックアウトまで、顧客の利用体験全体をカバーできるようにしたいと考えたとします。多くのサイトでは、フロー内のこれらのステップを次のようにパスを用いて指定します：「example.com/, example.com/shop/product1、 example.com/checkout」。Waiting Roomは設定されたパスの最後にワイルドカードを想定するため、これらのサイトではこのユースケースはすでに十分なものでした。したがって、example.com/に待機室を設置すれば、この顧客利用体験のあらゆる段階で関連することになるすべてのURLをカバーすることができました。このセットアップでは、一度待機室を通過したWeb訪問者は、Waiting Roomに対し同一のユーザーであることをURL間の遷移の際に明示する同一待機室のクッキーを使用しているため、ユーザーフローのどのステップでも再キューされなおすことはありません。

しかし、多くのサイトでは、パスの代わりもしくはパスと併せサブドメインを使い、この種のショッピングフローの各段階を区切っています。例えば、多くのサイトでは、チェックアウトページをcheckout.example.comのような別のサブドメインに置いています。以前は、このようなサイト構造を持つ顧客がサイト全体を単一の待機室で保護する場合、example.com/ に待機室をデプロイし、checkout.example.com/に別の待機室を配置する必要がありました。このやり方は、多くの顧客にとって理想的なものではありませんでした。あるサイトのWeb訪問者が、同じ顧客利用体験の2つの異なる部分でキューに入れられる可能性があったからです。これは、checkout.example.com/の待機室がexample.com/をカバーするのではなく、Web訪問者を別のユーザーとして同じカウントすることが理由です。

とはいえ、1つのサイトで待機室を分けた方が賢明な場合もあります。例えば、チケット販売Webサイトは、そのエイペックスドメイン（example.com）に待機室を置くことができます。 また、特定のイベント（example.com/popular_artist_tour）のページでは、プレキューを持つ個別の待機室を設定しています。example.com/に設定された待機室は、あるイベントのチケット販売が開始されたときに、サイトへの主要な入り口が圧倒されてクラッシュすることがないようにします。 特定のイベントページに置かれた待機室は、サイトの他の部分に行くトラフィックに影響を与えることなく、単一のイベントのためのトラフィックがイベントの前にキューを開始できることを保証します。

最終的には、顧客がサイトの保護に1つまたは複数の待機室を望むかどうかにかかわらず、当社は顧客がユースケースとサイト構造に最適な待機室をデプロイする柔軟性を提供したいと考えました。今回、Waiting Roomが単一の待機室で複数のホスト名とパスカバレッジに対応できるようになったことを発表できることを大変うれしく思います。

マルチホストとパスカバレッジの始め方

今回、同じゾーンに属する複数のホスト名とパスの組み合わせ（またはルート）に待機室を設定できるようになりました。Traffic > 待機室を開き、Create（作成）を選択します。ドメイン名は、すでに入力されています。待機室設定にさらにルートを追加するには、Add Hostname and Path（ホスト名とパスの追加）を選択します。次に、同じ待機室にカバーさせる別のホスト名とパスを入力してください。各パスの最後はワイルドカード扱いとなります。そのため、待機室にカバーさせたいURLごとに待機室を作成する必要はありません。すでに入力した他のホスト名とパスの組み合わせではカバーできないURLに対してのみ、追加ルートを作成してください。

複数のホスト名とパスの組み合わせをカバーする待機室をデプロイする場合、この待機室用にユニークなクッキー名を作成する必要があります（詳細は後述します）。その後、普段と同じワークフローで待機室をデプロイしてください。

多言語待機室のデプロイ

多言語サイトを1つの待機室でカバーできること、つまり言語ごとに異なるテキストを提供しながら、すべてのサイトトラフィックを同じ待機室の制限にカウントできることは、お客様からよく寄せられていた要望でした。異なる言語オプションを区別するためにサイトを構成する方法はいろいろある中、最も一般的なのはサブドメインかパスによる方法です。パス区切りが使われているサイトでは、example.com/enやexample.com/esのようになります。それぞれ英語とスペイン語に対応するものです。サブドメイン区分を使用するサイトでは、en.example.com/、およびes.example.com/のようになります。マルチホスト待機室がカバーする以前は、サブドメインのバリエーションは単一の待機室ではカバーできませんでした。

Waiting Roomの既存の設定オプションでは、すでにパスのバリエーションに対応していました。しかし、これは顧客がサイト全体をゲートしたい場合にのみ、example.com/に待機室を置くことで可能でした。多くのeコマースのお客様から、同じ商品を販売する需要の高い商品ページを異なる言語オプションでゲート表示できるようにしてほしいという要望がよせられていました。例えば、example.com/en/product_123、および example.com/es/product_123の両方のURLをカバーするために同じ待機室とトラフィック制限が望まれていました。これまでは、複雑なバイパスルールのロジックがなければそれは不可能でした。

今では、お客様は多言語サイトの構成のために、サブドメインまたはパスのアプローチのいずれかに対応する待機室をデプロイできるようになりました。残る唯一のステップは、ユーザーが待機室にキューイングされているときに異なる言語を提供するように待機室を設定することです。これは、URLを読み込んでロケールを決定し、テンプレート内で各ロケールに適切な翻訳を定義するテンプレートを構築することで実現できます。

以下は、URLパスからロケールを決定し、翻訳されたテキストを表示するテンプレートの例です：

<!DOCTYPE html>
<html>
  <head>
    <title>Waiting Room powered by Cloudflare</title>
  </head>
  <body>
    <section>
      <h1 id="inline-msg">
        You are now in line.
      </h1>
      <h1 id="patience-msg">
        Thank you for your patience.
      </h1>
    </section>
    <h2 id="waitTime"></h2>

    <script>
      var locale = location.pathname.split("/")[1] || "en";
      var translations = {
        "en": {
          "waittime_60_less": "Your estimated wait time is {{waitTime}} minute.",
          "waittime_60_greater": "Your estimated wait time is {{waitTimeHours}} hours and {{waitTimeHourMinutes}} minutes.",
          "inline-msg": "You are now in line.",
          "patience-msg": "Thank you for your patience.",
        },
        "es": {
          "waittime_60_less": "El tiempo de espera estimado es {{waitTime}} minuto.",
          "waittime_60_greater": "El tiempo de espera estimado es {{waitTimeHours}} de horas y {{waitTimeHourMinutes}} minutos.",
          "inline-msg": "Ahora se encuentra en la fila de espera previa.",
          "patience-msg": "Gracias por su paciencia.",
        }
      };

      {{#waitTimeKnown}}
      var minutes = parseInt( {{waitTime}} , 10);
      var time = document.getElementById('waitTime');

      if ( minutes < 61) {
        time.innerText = translations[locale]["waittime_60_less"]
      } else {
        time.innerText = translations[locale]["waittime_60_greater"]
      }
      {{/waitTimeKnown}}

      // translate template text for each of the elements with “id” suffixed with “msg”
      for (const msg of ["inline-msg", "patience-msg"]) {
        const el = document.getElementById(msg);
        if (el == null) continue;
        el.innerText = translations[locale][msg];
      }
    </script>
  </body>
</html>

テンプレートの仕組みは、次のようなものになります：ページのレンダリング後、`<script />` 内で `/en/product_123` や `/es/product_123`などさまざまなパスでロケールを区別しているサイトがある場合、ロケールは `location.pathname` から `locale = location.pathname.split(“/”)[1]` にて抽出されます。`translations`オブジェクトにロケールが指定されていない場合は、デフォルトで “en “になります。例えば、ユーザーがexample.com/product_123にアクセスした場合、デフォルトでは英語のテキストテンプレートがレンダリングされます。

同様に、サブドメインでサイト構造を切り分けているサイトで多言語待機室をサポートするには、URLからロケールを抽出する方法を更新するだけで済みます。`pathname`を見る代わりに、`window.location` の `hostname` プロパティの`locale = location.hostname.split(“.”)[0]` などのオブジェクトなどを見ます。この場合、en.example.com、es.example.comなどのサイト構造となっています。

上記のコードは、多言語待機室の構築を始めやすくできるよう当社で用意した開発者向けドキュメントに記載したスターターテンプレートの抜粋です。これらのテンプレートをダウンロードし、貴社サイトおよび貴社サイトが提供する言語オプションに沿ったルック＆フィールに仕上がるよう、編集できます。

これらのテンプレートは、それぞれのロケールに対して `translations` オブジェクトに翻訳を追加することで、さらに他の言語を含めて拡張できます。このように、ひとつのテンプレートで、サブドメインやパスを介してサイトが提供されるロケールに応じ複数の言語を提供できます。

複数のマルチホスト名とパスを持つ待機室でのクッキーの扱い方

待機室は 各ユーザに `__cfwaitingroom` クッキーを割り当て、そのユーザの状態を管理します。このクッキーは、ユーザーのキューの決定を行うために必要な他のプロパティに合わせてユーザーのキューを決定します。従来は、単一のホスト名とパスの設定には、クッキーを `__cfwaitingroom=[cookie-value]; Domain=example.com; Path=/es/product_123` と設定するだけで済みました。これにより、ページが再読み込みされた際、同じ待機室クッキーが送信され、それを調べて更新することができました。しかし、例えば `example.com/en/product_123`のように、異なるサブドメインやパスの組み合わせで同じクッキーを共有したいとき、これは簡単ではありませんでした。

複数のクッキーを設定するためのアプローチ

同じ待機室のクッキーを共有できるようにするために、当社ではブレインストーミングを行い、2つのアプローチを評価しました。

当社が考えた最初のアプローチは、HTTPレスポンスに複数の `Set-Cookie` ヘッダーを発行することでした。例えば、上記の多言語の例では、レスポンスヘッダーに次のように書くことができます：

Set-Cookie: __cfwaitingroom=[cookie-value]…Domain=example.com; Path=/en/product_123 …
Set-Cookie: __cfwaitingroom=[cookie-value]...Domain=example.com; Path=/es/product_123 …

この方法を使えば、同じ待機室に対して複数のホスト名とパスを扱うことができます。しかし、スケーラブルなソリューションとは言えません。 RFC6265ごとに、仕様で定義された厳密な制限はなく、ブラウザはその実装に固有の制限を持っています。例えば、ChromeではERR_RESPONSE_HEADERS_TOO_BIGでトランザクションを投げる前に、レスポンスヘッダが 256Kバイトまでの拡大を許容します。さらに、この場合、レスポンスヘッダは一意なホスト名とパスの組み合わせの数に比例して大きくなり、同じクッキー値 N（N は追加ルートの数）を何回も冗長に繰り返すことになります。このアプローチは、設定される必要があるホスト名とパスの組み合わせの限定されたリストを効果的に扱うことを可能にするものの、特定のサイトに対して相当数のルートが予想されるケースには理想的ではありませんでした。

当社が検討し最終的に採用することとなった2つ目のアプローチは、エイペックスドメイン（または最も共通するサブドメイン）にクッキーを設定することでした。つまり、ルーティングのリストから最も共通するサブドメインを割り出し、それをドメインとして使うのです。同様に、パスの場合、パスのリストから共有する最小のプレフィックスを決定し、それをpath属性に設定する値として使用することになります。例えば、a.example.com/shoes/product_123、および b.example.com/shoes/product_456の2つのルーティングが設定された待機室を考えてみましょう。

クッキーに設定されるドメインを決定するに当たり、ドメインのリストの中で `example.com` が最も共通するサブドメインであることがわかります。最も共通するサブドメインアルゴリズムを適用すると、ドメインとして `example.com` が得られます。パスの集合である `/shoes/product_123` と `/shoes/product_456` に対して最小共通接頭辞アルゴリズムを適用すると、パスとして `/shoes` が得られます。したがって、set-cookieヘッダーは次のようになります：

Set-Cookie: … __cfwaitingroom=[cookie-value]; Domain=example.com; Path=/shoes …

これで、Web訪問者がこの待機室がカバーするページのいずれかにアクセスするとき、Waiting Roomが正しいクッキーを受け取り、応答ヘッダーに Set-Cookie のみが含まれるようにできます。

しかし、当社はまだここまで到達できていません。共通のサブドメイン（またはエイペックスドメイン）と共通のパスプレフィックスを識別することはできても、ある待機室からのルーティングが別の待機室と重なってしまうと、まだ残る問題があります。例えば、特別な靴を販売している同じサイトに2つの待機室を設定するとします：

Waiting Room A
    a.example.com/shoes/product_123
    b.example.com/shoes/product_456

Waiting Room B
    c.example.com/shoes/product_789
    d.example.com/shoes/product_012

前述と同じアルゴリズムを適用すれば、2つのクッキーに同じドメインとパスのプロパティが設定されることになります。待機室Aの場合、ドメインは `example.com`、パスは`/shoes` となります。同様に、待機室Bでは、最も共通するサブドメインは同じくexample.comとなり、最も共通していないパスの接頭辞は `/shoes` となります。これにより、2つのクッキーを効果的に区別することができなくなり、Web訪問者を正しい待機室に導くことができなくなります。重複するクッキーネームの問題を解決するために、お客様のゾーンに固有のカスタムサフィックスを設定する要件を導入しました。これが、複数のホスト名やパスをカバーする待機室を設定する際、カスタムクッキーサフィックスの提供が必要な理由となります。したがって、待機室Aにクッキー接尾辞 “a “を、待機室Bにクッキー接尾辞 “b “を割り当てた場合、2つの `Set-Cookie` の定義は以下のようになります：

Waiting Room A

Set-Cookie: __cfwaitingroom_a=[cookie-value]; Domain=example.com; Path=/shoes

Waiting Room B

Set-Cookie: __cfwaitingroom_b=[cookie-value]; Domain=example.com; Path=/shoes

Web訪問者が、2つの異なる待機室が設定されたページにリクエストを行うと、待機室は指定されたリクエストに対応するクッキーを区別して選択し、これを用いて、ユーザーがサイト上のどこにいるかに応じ、そのユーザーに適用される待機室の設定を決定します。

Waiting Roomがマルチホストとマルチパス対応となったことで、お客様のサイトにWaiting Roomを組み込むための柔軟な選択肢を提供できるようになりました。これにより、Web訪問者に可能な限り優れたエクスペリエンスを提供しながら、トラフィックの多い時間帯にサイトを保護できるようになりました。 お客様のサイトは、トラフィックの急増から常に保護されることになります。Waiting Roomをさっそくお試しいただき、またWaiting Roomアドバンスの詳細について当社へのお問い合わせをお待ちしています。

Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=ZKnXxvc5WB0