Project

General

Profile

Anomalie #4129

Echec de la première connexion des utilisateurs LDAP et non création de leur compte

Added by Franck R almost 3 years ago. Updated almost 3 years ago.

Status:
En cours
Priority:
Normal
Assignee:
-
Category:
authentification
Target version:
Start date:
04/11/2018
Due date:
% Done:

0%

Resolution:
Navigateur:

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 ).

  1. Le site SPIP est configuré pour utiliser l'authentification LDAP ;
  2. Un nouvel utilisateur est créé dans le LDAP ;
  3. Il se connecte au site SPIP avec ses identifiants LDAP ;
  4. 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 :
  1. La création de l'utilisateur à la main dans la base de donnée permet à l'utilisateur de se connecter (insert into spip_auteurs ...)
  2. 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

  • 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

b b a écrit :

Salut et merci pour le signalement, on dirait bien que ton bug est le même que celui signalé dans #3919, tu confirmes ?

Le bug #3919 est celui auquel je fais référence par "bug de config LDAP", mais pas le bug rapporté.

#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

J'ai comme l'impression qu'il y a incompréhension :)

Peux-tu vérifier que ça fonctionne ou non, en appliquant les modifications proposées dans #3918 & #3919 ?

#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.

Also available in: Atom PDF