General information

Backoffice

The backoffice is a web interface hosted by dydu servers. They allow bot configuration and analytics analysis.

• The web interface of the solution is password-protected. In order not have it shared in clear text on the network, the identification page is accessible only with https protocol. We also have a class-2 certificate issued by StartSSL.

• The inactivity duration of a session has been set to 15 minutes in order to compensate forgetting to disconnect from the interface.

• No password is sent in the emails when registering to service or when resetting the password.

Dialog box

The dialog box is added to the HTML pages of the target site by querying javascript script hosted on the dydu servers.

• The javascript code of the dialog box is minified.

• This javascript code is only there to draw the window and make the request to the server, so it does not contain any sensitive code. The only the data about to the bot is its ID.

• The identifier of the bot is a UUID (Universal Unique Identifier), namely a unique identifier encoded on 128 bits. Thus, the identifier is not a sequence, and it is almost impossible to find an identifier of a bot without knowing it.

• The dialog box stores cookies on the client's computer, but there is no sensitive information, and they are not required for the bot to operate. They are used to improve the user experience by allowing continuity in the dialog when the user changes pages.

• The dialog box can be configured to query the web service by using the secure https protocol. The exchanges are then encrypted.

Processing requests

Each question of a user to the bot triggers a request of type GET.

The arrival of a question is handled by the dialog engine on the server.

• If a bot is invoked too often in a too short time, requests are no longer processed by the dialog engine, so as to avoid a denial of service.

• Sentences that are too long are not processed by the engine. This verification is carried out both by the javascript code and by the server.

• The only processing done on the chains of user questions is cutting them into tokens. The dialog engine then works only with these tokens. It is therefore not possible to perform a SQL injection or any other operation.

Server infrastructure

The server hosts both the web interface and the dialog engine.

• The ssh and mysql ports are not the default ports.

• Ports for services used internally only are blocked from the outside.

• It is not possible to access it in ssh directly, it is necessary to go through the pre-production machine.

• The shell does not save command history so that no password appears in plain text.

• All passwords, both technical and the users of the solution, are stored / encrypted.

• All services and middleware are launched by users with limited rights.

• Exceptions generated in pre-production and in production are reported per email, as well as the javascript errors that occur in the dialog boxes.

Availability of service

In order to achieve maximum service availability, we have implemented several ways that also enable us to ensure that service is not denied on the solution.

• The releases are launched via scripts in order to reduce the time it takes to start production of the service and to ensure that no oversight possible.

• Each release is preceded by a pre-production phase during which tests are carried out.

• a backup of the database, which includes knowledge, analytics and dialogs, is done every day and saved for a week.

• A back-up server takes over if there is a failure of the main server.

  • The switch is seamless for users and for our customers.

  • The knowledge base used is the one that was saved the day before. The knowledge base of the backup server is read-only.

  • When the primary server is available again, the dialogs that took place on the back-up server are moved to calculate analytics on the totality of dialogs.

  • This back-up server is hosted by another provider.

  • When the main server is brought into production, the back-up server is solicited until the new release. The service is never interrupted.

Server usage

On this page you will find all the information about the use of backup servers in case of difficulties on the main server.

General information

• The main server can be queried when the user starts to enter a question in order to avoid waiting times when the main server is checked up;

• In case of errors or unavailability of the main server (APP1), a redirection protocol addressing the request to the backup server (APP2) must be implemented. This redirection must be carried out in the event of HTTP errors of category 400 (access denied) and 500 (server error);

• It may happen that the main server (APP1) is heavily slowed down but still functional. In this case, it is recommended to set timeouts in order to switch to the backup server;

• There is no backup server in the pre-production environment;

• If an error occurs during a conversation, a new conversation will be created on the backup server. There is no continuity;

• Once a conversation has been transferred or initiated on the standby server, it must remain on the standby server until the end of the conversation.