Release Candidate 3.5.1 RC0

[ynaessens]

Cette branche apporte deux modifications majeures :

• les champs login, etc. sont allongés pour compatibilité avec certains SSO,
• le cryptage des mots de passe est changé de md5 à password_hash().

Sauf retours négatifs, cette version sera proposée en stable d'ici à trois semaines.

---

This discussion was created from the release Release Candidate 3.5.1 RC0.

[zpaul91]

Bonjour
La version GRR 3.5.1 va t elle prochainement passer à stable ?
Merci.

[ynaessens]

Bonjour,
je viens d'étudier votre PR. Je ne comprends pas pourquoi vous ajoutez la condition source = 'local' dans la requête puisqu'on cherche à ce point un utilisateur à identifier en LDAP ou IMAP. D'accord pour la désactivation de SE3, dont je doute aujourd'hui que ce soit encore utile.
Merci pour votre contribution et vos explications à venir ;-)

[zpaul91]

Rebonjour,
La requete cherche à vérifier si on a un utilisateur qui correspond à ce login dans la base des utilisateurs.
Si on regarde la suite, si pas de résultat, on tente l'authentification extérieure (LDAP, SSO, IMAP, ...)
Sinon, on appelle le checkPassword, donc l'utilisateur est reconnu comme "local", avec un password.

Cela semble venir de l'introduction du hash password, où on ne peut pas simplement faire la requete pour tenter de trouver un utilisateur qui répond au couple login/pass directement en base. Quand on avait une correspondance, on tentait l'auth LDAP/SSO/IMAP : c'est le comportement que j'ai voulu remettre en place. Il y a sans doute autre méthode, mais ça fonctionne sous LDAP (donc, ça devrait aussi fonctionner sous SSO etc. mais je n'ai pas le moyen de tester le SSO).

[ynaessens]

Je vois.
L'erreur que j'avais faite était donc de rechercher l'utilisateur en base sans tester la source ?
Ensuite, la deuxième connexion se passe bien ?
Pas de souci de casse majuscule/minuscule sur les identifiants ? J'ai un doute sur l'introduction de strtoupper()...

[zpaul91]

Je pense que c'est l'erreur oui, car par défaut si on trouve l'utilisateur, alors on passe à la vérification des passwords et de l'inactivité du compte.
La deuxième connexion se passe bien, aussi la première connexion.
Pour l'introduction de strtoupper, pas de problème : UPPER(login) login met le champ login en majuscule, donc, la condition WHERE vérifie majuscule vs majuscule.

[ynaessens]

Un grand merci !
Je reprends votre proposition.
Bonne journée à vous aussi.