Connexion à LDAP dans l'API - Partie 2

[prytoegrian]

Cf. https://github.com/libertempo/web/wiki/R%C3%A9union-d'%C3%A9quipe-ao%C3%BBt-2018#compatibilit%C3%A9-api--ldap

Nous avions pour objectif de réaliser la compatibilité entre l'API et LDAP. Après deux petits détours (cf. libertempo/docker#30 et libertempo/web#727), j'ai pu enfin m'atteler à ça. Ça a été long, la faute à des disponibilités aléatoires et une incompétence notoire sur la distinction entre newable et injectable qui m'a fait tourner en bourrique.

Le résultat est là, fonctionnel, #49 ayant bien préparé le terrain. Cette PR place donc la responsabilité de la connexion LDAP dans l'API, moyennant l'utilisation d'une Factory qui a pour responsabilité d'abstraire le choix du connecteur et que le reste de l'appli n'ai en aucune façon besoin de savoir quel est le type de connexion. À but de souplesse, j'ai mis en place une classe qui gère les connecteurs CAS et SSO de la même façon qu'avant, c'est-à-dire avec le mot de passe « none », la connexion ayant été réalisée côté web. Par la suite, nous n'aurons qu'à placer les bonnes classes de connecteur dans la Factory pour que ça fonctionne tout seul.

Il va sans dire que j'ai dû ajouter une nouvelle dépendance, AdLDAP, elle a l'air de pouvoir nous fournir tous nos besoins, est activement maintenue et a une conception propre, la garantie d'une pérennité et d'une robustesse donc.

Le test peut se faire en binomage avec le nouveau docker et la tentative de connexion de l'utilisateur hr / hrldap dans tous les cas de figures :

• dans LDAP mais pas dans l'appli,
• dans LDAP et dans l'appli,
• pas dans LDAP,
• pas de connexion LDAP,
• mauvaise conf LDAP,
• ...

Une autre PR devra être faite dans web pour ne plus chercher à se connecter et laisser l'API faire son travail. Après ça, la version sera bonne pour livraison.

[prytoegrian]

Testée. Je m'attele à l'autre.