Zendesk cuenta con un conjunto sofisticado de sistemas de protección contra abusos que protegen todas las instancias de Zendesk y la estabilidad general de la plataforma. La mayoría de los clientes de Zendesk y sus clientes (usuarios finales) acceden a Zendesk directamente a través de Internet. Zendesk supone que esta es la configuración estándar. Los clientes que no usen este estándar podrían tener problemas al conectarse a Zendesk.
Por ejemplo, una organización podría querer que sus agentes y usuarios finales accedan a Zendesk desde un único punto de acceso o su propia CDN configurando un proxy inverso. El proxy inverso intercepta las solicitudes de los clientes web que intentan acceder a Zendesk y las reenvía a Zendesk. Los clientes web nunca se comunican directamente con Zendesk. Solo el proxy se comunica directamente con Zendesk.
Zendesk no puede impedir que los clientes configuren su acceso de esta manera. Sin embargo, este es un uso no estándar y podría dar lugar a un comportamiento indeseado, incluido lo siguiente:
- Problemas con la administración de bots (CAPTCHA): si todas las solicitudes llegan a través de una sola IP o un solo ASN, es más probable que los usuarios sean identificados como bots aunque sean legítimos. La probabilidad es aún mayor si el proxy o CDN cambia los encabezados HTTP de alguna manera.
- Rechazo de los rastreadores de motores de búsqueda y otros bots “buenos”: Cloudflare identifica los bots buenos en parte a través de las IP y los ASN de las solicitudes. Por ejemplo, si una solicitud con un usuario-agente de Googlebot tiene una IP de solicitud que es diferente a las IP registradas de Google, esta será rechazada por Cloudflare.
- Indexación de las páginas incorrectas. Si no lo rechaza Cloudflare, lo más probable es que los rastreadores de búsqueda traten de usar el URL canónico proporcionado por las etiquetas de metadatos del sitio de Zendesk. Si un motor de búsqueda llega a rastrear un sitio mediado por proxy, lo que sucedería es que indexaría las páginas con los URL que no cuentan con proxy.
- Límite de velocidad: los límites de velocidad se aplican en función de la IP de la solicitud. Si todas las solicitudes de los clientes pasan por una sola dirección IP o un conjunto pequeño de direcciones IP, es más probable que se apliquen límites de velocidad.
- Problemas con la memoria caché: si la configuración del proxy o la CDN tiene lógica de caché personalizada, Zendesk no puede garantizar la integridad de esa memoria caché. Por ejemplo, los artículos borrados podrían ser visibles por más tiempo en el proxy que en el centro de ayuda. Los cambios en los permisos también podrían demorarse.
Antes de usar un proxy inverso, piense si en realidad es necesario. Si tiene que cambiar el URL de su centro de ayuda, otra opción es usar el mapeo de host. Consulte Mapeo de host - Cambiar el URL de su centro de ayuda.
Pautas
Si el uso de un proxy inverso para acceder a Zendesk es inevitable, tenga en cuenta las siguientes pautas:
-
Todo el tráfico que pase a través del proxy debe usar varias IP de salida para que no se limite la velocidad ni haya riesgo de que parezca un bot.
-
Los proxies inversos deben ser transparentes y no deben manipular los encabezados de manera alguna (por ejemplo, hay que evitar que sobrescriban al usuario-agente).
De todas maneras, es posible que el tráfico sea clasificado como tráfico de bot por los sistemas de Zendesk. Si sigue estas pautas y sigue teniendo problemas, contacte al departamento de TI para solicitar ayuda.
0 comentarios