Zendesk dispose de systèmes robustes de protection contre les abus qui protègent toutes les instances Zendesk et la stabilité globale de la plateforme. La plupart des clients Zendesk et leurs clients (utilisateurs finaux) accèdent à Zendesk directement via Internet et Zendesk s’appuie sur cette configuration standard. Il est possible que les clients qui n’utilisent pas cette méthode standard rencontrent des problèmes quand ils se connectent à Zendesk.
Par exemple, une entreprise peut vouloir que ses agents et ses utilisateurs finaux accèdent à Zendesk à partir d’un point d’accès unique ou de leur propre réseau cloud (CDN) en configurant un proxy inverse. Le proxy inverse intercepte les demandes des clients Web qui essaient d’accéder à Zendesk et les transfère à Zendesk. Les clients Web ne communiquent jamais directement avec Zendesk. Seul le proxy communique directement avec Zendesk.
Zendesk ne peut pas empêcher les clients de configurer leur accès de cette façon, mais il s’agit d’une utilisation non standard et elle peut provoquer des comportements indésirables, notamment :
- Problèmes de gestion des bots (CAPTCHA) - Si toutes les demandes passent par une seule adresse IP ou ASN, elles ont plus de risques d’être identifiées comme des bots alors même que ce sont des utilisateurs légitimes. Ce risque est accru si le proxy ou le CDN modifie les en-têtes HTTP.
- Rejet des crawlers de moteur de recherche et autres « bons » bots - Cloudflare identifie les bots non malveillants en partie grâce aux adresses IP et ASN. Par exemple, si une demande avec un agent utilisateur du robot d’indexation de Google (Googlebot User Agent) a une adresse IP de demande différente des adresses IP enregistrées de Google, elle sera rejetée par Cloudflare.
- Indexation des mauvaises pages - S’ils ne sont pas rejetés par Cloudflare, les crawlers de moteur de recherche essaieront probablement d’utiliser l’URL canonique fournie par les balises de métadonnées du site Zendesk. Par conséquent, si un moteur de recherche explore un site proxifié, il indexe les pages avec des URL non-proxifiées.
- Limites de débit - Les limites de débit dépendent de l’adresse IP de demande. Si toutes les demandes des clients passent par une seule ou un petit nombre d’adresses IP, il y a plus de chances que les limites de débit soient appliquées.
- Problème de cache - Si votre configuration proxy ou CDN utilise une logique de cache personnalisé, Zendesk ne peut pas garantir l’intégrité de ce cache. Par exemple, les articles supprimés peuvent être visibles plus longtemps dans le proxy que dans le centre d’aide. Les modifications des permissions peuvent aussi subir des retards.
Avant d’utiliser un proxy inverse, demandez-vous si c’est vraiment nécessaire. Si vous devez changer l’URL de votre centre d’aide, vous devriez peut-être plutôt envisager d’utiliser le mappage d’hôte. Consultez Mappage d’hôte - Modification de l’URL de votre centre d’aide.
Instructions
Si vous êtes obligé d’utiliser un proxy inverse pour accéder à Zendesk, n’oubliez pas les points suivants :
-
Tout le trafic qui passe par le proxy doit utiliser plusieurs adresses IP pour éviter les limites de débit et ne peut pas être pris pour un bot.
-
Les proxys inverses doivent être transparents et ne doivent pas manipuler les en-têtes, par exemple en remplaçant l’agent utilisateur.
Malgré tout, il est possible que les systèmes Zendesk identifient encore ce trafic comme des bots. Si vous suivez ces directives et rencontrez encore des problèmes, contactez votre service informatique pour obtenir de l’aide.
0 commentaire
Vous connecter pour laisser un commentaire.