[BUG] Aucune réponse de l'API après une erreur de connexion au LDAP

[wouldsmina]

Bonjour,

Nous avons rencontré une défaillance de l'authentification CAS pour l'ensemble de nos utilisateurs suite à une erreur dans esup-otp-cas (version 1.7.2) :

janv. 06 08:00:48 velos-otp node[556]: 2025-01-06 08:00:48 ERROR Error: Socket error. Message type: SearchRequest (0x63)
janv. 06 08:00:48 velos-otp node[556]: read ECONNRESET
janv. 06 08:00:48 velos-otp node[556]:     at Socket.socketError (file:///usr/local/lib/esup-otp-api/node_modules/ldapts/dist/index.mjs:3528:13)
janv. 06 08:00:48 velos-otp node[556]:     at Socket.emit (node:events:519:28)
janv. 06 08:00:48 velos-otp node[556]:     at emitErrorNT (node:internal/streams/destroy:169:8)
janv. 06 08:00:48 velos-otp node[556]:     at emitErrorCloseNT (node:internal/streams/destroy:128:3)
janv. 06 08:00:48 velos-otp node[556]:     at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
janv. 06 08:00:48 velos-otp node[556]: 2025-01-06 08:00:48 ERROR Error: Connection closed before message response was received. Message type: SearchRequest (0x63)
janv. 06 08:00:48 velos-otp node[556]:     at Socket.socketClose (file:///usr/local/lib/esup-otp-api/node_modules/ldapts/dist/index.mjs:3569:15)
janv. 06 08:00:48 velos-otp node[556]:     at Socket.emit (node:events:519:28)
janv. 06 08:00:48 velos-otp node[556]:     at TCP.<anonymous> (node:net:339:12)

Suite à cette unique erreur, l'api ne répondait plus à aucune requête, sans retour d'erreur ni log. un restart du service a corrigé le problème.

Je n'ai pas trouvé d'explication à la coupure de connexion entre l'api et le ldap au moment de la requête. Pour essayer de reproduire le bug, j'ai bloqué la connexion vers le ldap (avec un drop du firewall) et l'api ne répondait plus, mais après retrait du drop, l'api a fonctionner de nouveau sans avoir besoin de restart.

Au delà de ce bug précis, serait il possible de forcer l'api a répondre (une erreur ou un bypass) si le ldap ne répond pas après un certain temps ?

Cordialement.

[floriannari]

Bonjour,

Serait-il possible de forcer l'api a répondre (une erreur ou un bypass) si le ldap ne répond pas après un certain temps ?

Pour cela, dans databases/user/ldap.js, vous pouvez définir les paramètres "timeout" et "connectTimeout"

export async function initialize() {
    client = new Client({
        url: getLdapProperties().uri,
        timeout: 0, // Milliseconds client should let operations live for before timing out (Default: Infinity)
        connectTimeout: 0, // Milliseconds client should wait before timing out on TCP connections (Default: OS default)
    });
    await bindLdapIfNeeded();
}

Si cela convient, nous rendrons cela configurable directement dans le esup.json dans une future version

[wouldsmina]

je viens de tester et cela semble bien fonctionner. Le CAS saute l'étape MFA si timeout. Voici la réponse de l'api via swagger :

{
  "code": "Internal",
  "message": "Error: SearchRequest: Operation timed out"
}

Les valeurs que j'ai définit :

        timeout: 1000, // Milliseconds client should let operations live for before timing out (Default: Infinity)
        connectTimeout: 100 // Milliseconds client should wait before timing out on TCP connections (Default: OS default)

Merci.

Je me demandais aussi s'il y avait une url pour contrôler le statut de l'API ? J'aimerais le monitorer pour être alerté en cas de nouveau problème de ce genre.

[floriannari]

Ici on fait une simple requête classique (du genre GET /protected/users/toto) pour contrôler le statut du serveur