Informations générales
Backoffice
Le backoffice est une interface web hébergée par les serveurs de dydu. Ils permettent la configuration du bot et l'analyse des statistiques.
L'interface web de la solution est protégée par mot de passe. Afin de ne pas le faire transiter en clair sur le réseau, la page d'identification n'est accessible que sur le protocole https. Nous disposons par ailleurs d'un certificat de classe 2 délivré par la société StartSSL.
La durée d'inactivité d'une session a été fixée à 15 minutes, afin de pallier aux oublis de déconnexion de l'interface.
Aucun mot de passe n'est envoyé dans les emails lors de l'inscription au service ou lors de la réinitialisation du mot de passe.
Boîte de dialogue
La boîte de dialogue s'ajoute sur les pages HTML du site cible par l'appel à un script javascript hébergé sur les serveurs de dydu.
Le code javascript de la boîte de dialogue est minifié.
Ce code javascript ne sert qu'à dessiner la fenêtre et effectuer la requête de dialogue vers le serveur, il ne contient donc aucun code sensible. La seule donnée relative au bot est son identifiant.
L'identifiant du chatbot est un UUID (Universal Unique Identifier), à savoir un identifiant unique codé sur 128 bits. Ainsi, l'identifiant n'est pas une séquence, et il est quasiment impossible de retrouver l'identifiant d'un bot sans le connaître.
La boîte de dialogue stocke des cookies sur le poste client, mais n'y place aucune information sensible, et ils ne sont pas indispensables au fonctionnement. Ils sont utilisés pour améliorer l'expérience utilisateur en permettant la continuité de la conversation lorsque l'internaute change de page.
La boîte de dialogue peut être configurée pour interroger le service web en utilisant le protocole sécurisé https. Les échanges sont alors chiffrés.
Traitement des requêtes
Chaque question d'un utilisateur au bot déclenche une requête de type GET.
L'arrivée d'une question est traitée par le moteur de dialogue sur le serveur.
Si un bot est sollicité trop souvent dans un délai trop court, les requêtes ne sont plus traitées par le moteur de dialogue, de sorte à éviter un déni de service.
Les phrases trop longues ne sont pas traitées par le moteur. Cette vérification est effectuée à la fois par le code javascript et par le serveur.
Le seul traitement effectué sur les chaînes des questions des utilisateurs est le découpage en tokens. Le moteur de dialogue ne travaille ensuite qu'avec ces tokens. Il n'est donc pas possible d'effectuer une injection SQL ou autre.
Infrastructure serveur
Le serveur héberge à la fois l'interface web et le moteur de dialogue.
Les ports ssh et mysql ne sont pas les ports par défaut.
Les ports des services utilisés en interne seulement sont bloqués pour l'extérieur.
Il n'est pas possible d'y accéder en ssh directement, il faut passer par la machine de pré-production.
Le shell ne conserve pas d'historique des commandes afin de ne pas laisser de mot de passe en clair.
Tous les mots de passe, aussi bien techniques que ceux des utilisateurs de la solution, sont stockés/cryptés.
L'ensemble des services et middlewares sont lancés par des utilisateurs à droits limités.
Les exceptions générées en pré-production et en production sont remontées par email, ainsi que les erreurs javascript qui se produisent sur les boîtes de dialogue.
Disponibilité du service
Dans le but d'obtenir une disponibilité de service maximale, nous avons mis en place plusieurs moyens qui nous permettent également de nous assurer que la solution n'est pas victime d'un déni de service.
Les mises en production sont lancées via des scripts de sorte à réduire le temps de mise en production du service et de s'assurer qu'aucun oubli n'est possible.
Chaque mise en production est précédée d'une phase de mise en préproduction pendant laquelle des tests sont effectués.
un backup de la base de données, qui comprend à la fois les connaissances, les statistiques et les conversations, est effectué tous les jours et est conservé pendant une semaine.
Un serveur de secours prend le relais en cas de défaillance du serveur principal.
La bascule s'effectue de manière transparente pour les internautes et pour nos clients.
La base de connaissances utilisée est celle qui aura été sauvegardée la veille. La base de connaissances du serveur de secours n’est accessible qu’en lecture seule.
Lorsque le serveur principal est de nouveau disponible, il rapatrie les conversations ayant eu lieu sur le serveur de secours de sorte à pouvoir calculer les statistiques sur l’intégralité des conversations.
Ce serveur de secours est hébergé chez un autre fournisseur.
Lors d'une mise en production du serveur principal, le serveur de secours est sollicité le temps de la montée de version. Ainsi, le service n'est jamais coupé.
Usage des serveurs
Vous trouverez sur cette page toutes les informations relatives à l'usage des serveurs de secours en cas de difficultés sur le serveur principal.
Informations générales
L'interrogation du serveur principal peut être effectuée lorsque l'utilisateur commence à saisir une question afin d'éviter les temps d'attente lors du check up du serveur principal ;
En cas d'erreurs ou d'indisponibilités du serveur principal (APP1), un protocole de redirection adressant la requête sur le serveur de secours (APP2) doit être mis en place. Cette redirection doit être effectuée en cas d'erreurs HTTP de catégorie 400 (accès refusé) et 500 (erreur serveur) ;
Il peut arriver que le serveur principal (APP1) soit fortement ralenti mais toujours fonctionnel. Dans ce cas précis, il est recommandé de placer des timeouts afin d'effectuer la bascule vers le serveur de secours ;
Il n'y a pas de serveur de secours en environnement de pré-production ;
Si une erreur survient pendant une conversation, une nouvelle conversation sera créée sur le serveur de secours. Il n'y a pas de continuité ;
Une fois qu'une conversation a été transférée ou initiée sur le serveur de secours, il faut que celle-ci demeure sur ce même serveur jusqu'à la fin de la conversation.
Dernière mise à jour