Anomalie #4129
Echec de la première connexion des utilisateurs LDAP et non création de leur compte
0%
Description
version de SPIP : 3.2.1 [23954]
version de PHP : 5.6.33
version de MySQL : 14.14
Jusqu'à il n'y a pas si longtemps (désolé pour l'imprécision, on ajoute pas des utilisateurs si fréquemment), les utilisateurs LDAP pouvaient s'authentifier sur SPIP et l'utilisateur SPIP était créé dans la base de donnée. J'ai remarqué récemment que les nouveaux arrivants ne pouvaient plus s'authentifier, et donc créer leur compte, de cette manière.
Problème¶
Ce problème a été remarqué sur le site en production mis à jour en 3.2.1, ainsi que sur une installation de test 3.2.1 propre (attention au bug de config LDAP ).
- Le site SPIP est configuré pour utiliser l'authentification LDAP ;
- Un nouvel utilisateur est créé dans le LDAP ;
- Il se connecte au site SPIP avec ses identifiants LDAP ;
- La connexion échoue systématiquement.
La demande #3824 offre une solution avec _AUTORISER_AUTH_FAIBLE mais elle ne me semble pas satisfaisante sachant que LDAP est configurable à l'installation de SPIP, le mode par défaut devrait assurer que l'on puisse se connecter.
Workaround¶
Il y a au moins deux solutions qui fonctionnent :- La création de l'utilisateur à la main dans la base de donnée permet à l'utilisateur de se connecter (
insert into spip_auteurs ...) - Mettre
define ('_AUTORISER_AUTH_FAIBLE', true);
Analyse¶
Lors de la toute première authentification d'un utilisateur inconnu de SPIP, le mot de passe est envoyé sécurisé par défaut (hachage réalisé par le javascript avec les aleas actuel/futur). Seulement l'authentification LDAP requiert le mot de passe en clair. Lorsque l'utilisateur existe déjà et que la source est ldap, alors la sécurisation du mot de passe est désactivée (login.js, login-sha-min.js, le cadenas à côté du champ mot de passe disparait), d'où le fonctionnement du workaround 1. Si on désactive la sécurisation du mot de passe, workaround 2, alors cela fonctionne lors de la première authentification, et l'utilisateur est bien créé dans SPIP.
Remarque¶
L'envoi en clair n'est pas un gros problème dans notre cas, le site est forcé en HTTPS.
History
#1
Updated by b b almost 3 years ago
Updated by - Status changed from Nouveau to En cours
- Target version set to 90. LDAP
Salut et merci pour le signalement, on dirait bien que ton bug est le même que celui signalé dans #3919, tu confirmes ?
#2
Updated by Franck R almost 3 years ago
Updated by #3
Updated by Franck R almost 3 years ago
Petite précisions sur le workaround 2, il faut préciser la source comme ldap :
insert into spip_auteurs (nom, statut, login, source, pass) values ("Foo", "1comite", "bar", "ldap", "");
#4
Updated by Franck R almost 3 years ago
workaround 1 pardon
#5
Updated by b b almost 3 years ago
#6
Updated by Franck R almost 3 years ago
La modification #3919 n'est pas liée, elle ne concerne que le fichier de configuration, elle ne règle donc pas le problème. Comme je l'ai précisé, je n'ai pas patché SPIP, vu que cela ne concerne que l'installation, j'ai édité le fichier connect.php après installation en remplaçant '','utf8' par 'ldap.php','utf8'
La modification #3918 n'est pas nécessaire non plus, le ldap.php ci-dessus évite d'avoir à ajouter le suffixe .php dans le code comme proposé dans ce patch, ce qui n'est valable que dans le cas où l'on spécifie simplement ldap.
#7
Updated by b b almost 3 years ago
Ok, je comprends mieux ton signalement, la piste serait donc d'appliquer la proposition de marcimat dans #3824, cf :
On peut activer cette constante lorsque le type d'authentification remarque que l'utilisateur peut être logé avec ce type d'authentification (si c'est possible, dans xx_retrouver_login() donc),
Du coup, le ticket ici-présent ne serait-il pas un doublon de #3824 ?
#8
Updated by Franck R almost 3 years ago
C'est pour cela que je mentionne cette demande effectivement, les problèmes sont connexes mais il ne s'agit pas d'un doublon pour moi : #3824 est une demande d'évolution, certes qui pourrait éventuellement régler le problème signalé, mais à mon avis il s'agit ici d'un bug, puisqu'il rend la connexion impossible via LDAP sur un site nouvellement créé/mis à jour. Seule l'utilisation d'un workaround permet de régler ce problème.
#9
Updated by b b almost 3 years ago
J'ai fais le lien entre les deux tickets, ceci afin qu'on oublie pas de fermer celui-ci le jour où on corrigera le premier.