lower(password) = lower($pwd) ???
Cela ne fonctionnera pas car le mot de passe stocké en base de données est encrypté (hash md5). Il n'y a aucun intérêt à passer la chaine md5 en lower. ;-)

Dans le code que j'ai donné, on récupère le hash du mot de passe pour le login entré en lower. Donc le select va devoir choisir entre le hash du mot de passe de "test" et de "TEST". Pourquoi choisit-il celui de "TEST" ? Pas encore compris. Surement une histoire de "last in, first out" (traduction au cas où : Le dernier enregistré est le premier à sortir).

Bonsoir ;

bon, je n'ai pas participé à la discussion hier soir, désolé.

LucMorizur a écrit:

Sinon une petite idée peut-être un peu bizarre pour patienter en attendant qu'un admin résolve le problème (...)

J'ai effectivement oublié un minuscule problème en proposant "test/pwd1 ou pwd2 OK, Test/pwd1 ou pwd2 OK, etc", car comment être sûr que l'identifiant proposé est "test" ou "Test" ?

Nouvelle proposition, donc :
lorsque $conf['insensitive_case_logon'] = true, un test est effectué pour savoir si la situation est saine (oui ou non, valeur stockée en DB). Si c'est oui, on continue comme avant.

Si c'est non, c'est qu'elle n'a pas encore été testée à saine (donc soit $conf['insensitive_case_logon'] vient d'être passée à true et la bonne différentiation des comptes n'a pas encore été testée, soit des comptes présentaient un problème de différentiation lors du dernier test). La première chose à faire à ce moment-là, c'est de tester la différentiation des comptes, ce qui est assez simple. S'il n'y a plus de problème de différentiation, on marque la situation comme saine (comme la création de comptes ne différant que par la casse est impossible tant que $conf['insensitive_case_logon'] est true, la situation ne peut normalement pas redevenir malsaine).

Maintenant si la situation est malsaine : il faut marquer les comptes présentant un problème de différentiation (une table spécifique, ou une liste des id en question dans la DB). Ceux-là ne pourront pas bénéficier de l'insensibilité à la casse lors de l'identification : si c'est un compte marqué comme tel, l'identification ne pourra être validée que si c'est exactement test/pwd1 et ne fonctionnera pas si c'est Test/pwd1, avec éventuellement un message à l'utilisateur évoquant une ambiguïté si l'identification rate, mais ça ce n'est pas forcément heureux.

Sinon :

Eric a écrit:

Je pense que l'email n'est pas forcément la méthode la plus efficace dans ce cas (voir les raisons données ci-dessus). Un bandeau d'avertissement sur la page d'admin serait mieux et plus immédiat. Mais là encore, quand l'afficher et, surtout, quand le retirer ? Lorsqu'il n'y a pas / plus de comptes multiples avec le même login à la casse près ?

Mmmh, alors peut-être à la fois un e-mail et un bandeau sur l'admin de la galerie.

Ce qu'il y a, c'est que le seul bandeau sur l'admin de la galerie ne suffit à mon avis pas, car on peut modifier $conf['insensitive_case_logon'] sans afficher l'admin de la galerie, en passant par FTP. Or il faut que le webmestre soit prévenu le plus vite possible.

Eric a écrit:

Et il faudrait alors donner les moyens à l'admin / webmaster de prévenir le / les utilisateur(s) inscrits concernés:
- Soit que leur login a été modifié arbitrairement par l'admin / webmaster. Pas top, relationnellement parlant.
- Soit qu'il doivent modifier leur login, ce qui ne servirait à rien puisque les utilisateurs ne peuvent pas modifier leur login et les obligeraient à créer un nouveau compte. Au final, on aurait toujours un compte "fantôme", faux doublon qui trainerait.

Cette partie-là est effectivement délicate.

Éventuellement, on peut peut-être établir (un peu contrairement à ce que j'ai écrit ci-dessus) que $conf['insensitive_case_logon'] ne peut pas être accepté comme "true" s'il y a ambiguïté dans la casse des username. Ça, c'est ce qui serait le plus simple au niveau de la programmation.

Maintenant si on accepte quand même $conf['insensitive_case_logon'] = true , si on fait comme décrit ci-dessus, les comptes "test" et "Test" pourront toujours s'identifier comme auparavant, ce sera plus ou moins transparent pour eux -- ce ne le sera pas si le webmestre annonce que "ça y est, mon site est insensible à la casse", mais le préjudice est tout de même assez mineur.

Ensuite, eh bien le webmestre a tout de même la possibilité de modifier le username par phpMyAdmin, à lui de le faire en communiquant comme il faut avec "test" et/ou "Test".

Eric a écrit:

Vraiment pas simple...

+1 :-/ ...

... mais pas irrésolvable -- à mon humble avis :-) !

Whiler a écrit:

Le nom d'utilisateur est une colonne comme une autre dans la base de données.. ce n'est pas une clé primaire utilisée dans d'autres tables.
Le mot de passe est encrypté par un code qui n'est pas lié à l'utilisateur.

Pourquoi ne pas rendre modifiable le champ Utilisateur depuis l'interface d'admin pour les Webmestres pour éviter d'avoir à passer par un phpMyadmin ?

Pourquoi pas. On ne rencontre pas cette possibilité très souvent, mais ce serait effectivement un plus.

Whiler a écrit:

Personnellement, je trouve toujours le bandeau suffisant...
Si je modifie des fichiers de config, je valide dans la foulée que tout continue de fonctionner.. dont la partie administration... sans parler des utilisateurs de tests que j'aurai créé dans ce cas spécifique pour valider ma modification et que j'irai ensuite purger depuis l'administration.

Justement, on ne fonctionne pas tous pareil. Pour moi aussi, le fonctionnement que tu décris est logique, mais il faut prévoir un maximum de situations, même certaines paraissant peu logiques. Enfin, je crois que c'est comme ça qu'il faut faire...

Whiler a écrit:

Pour l'email, il faut tout de même que quelqu'un se connecte sur le site pour qu'il soit envoyé (il n'y a pas de Cron..).

Effectivement ; mais bon, avec les robots, a priori, une galerie sur le net est visitée constamment.

Whiler a écrit:

Après, cela peut être éventuellement des options complémentaires.

Mmmmh, attention à ne pas rajouter trop d'options je pense.

Dernière modification par LucMorizur (2010-12-12 23:12:25)

Eric a écrit:

Messieurs Whiler et LucMorizur, vos analyses et idées sont tout à fait intéressantes. ^^

Après lecture de vos derniers messages, je pencherai de plus en plus pour un plugin spécifique qui se chargerait non seulement de gérer les identifications mais aussi les contrôles d'intégrité après activation de l'option $conf['insensitive_case_logon']. Cela permettrait déjà de débroussailler le sujet et proposer une solution stable qui n'impacterait pas la stabilité du core.

Ensuite, on pourra se pencher sur l'intégration éventuelle dans le core. Qu'en pensez-vous ?

Très bonne approche ;o)

Eric a écrit:

Personnellement, je n'aurai pas le temps de m'y consacrer dans l'immédiat. Mais si l'un de vous (ou les deux) souhaite se lancer, je veux bien participer. On pourrait ouvrir un projet commun :
- dans le bugtracker pour référencer ce qu'il y a lieu de faire, donner les priorités et définir qui fait quoi.
- dans svn pour partager nos travaux respectifs.

Avis ?

Là, ça se corse... mon dernier essai s'est soldé par une incapacité flagrante à réussir à déclencher quoi que ce soit dans le plugin que j'ai essayé de faire...
-Triturer du code existant, modifier les fichiers interdits, ça va ;o))
-me plugger sur les smarties.. pas réussi.. le plus loin où j'ai réussi à aller a été de créer une page d'admin, qui elle, veut bien s'afficher... mais j'ai jamais réussi à être appelé par la page d'enregistrement...et donc à y insérer la moindre donnée...

Mais dans le principe, je ne suis pas contre...

Eric a écrit:

Messieurs Whiler et LucMorizur, vos analyses et idées sont tout à fait intéressantes. ^^

Après lecture de vos derniers messages, je pencherai de plus en plus pour un plugin spécifique qui se chargerait non seulement de gérer les identifications mais aussi les contrôles d'intégrité après activation de l'option $conf['insensitive_case_logon']. Cela permettrait déjà de débroussailler le sujet et proposer une solution stable qui n'impacterait pas la stabilité du core.

Ensuite, on pourra se pencher sur l'intégration éventuelle dans le core. Qu'en pensez-vous ?

Personnellement, je n'aurai pas le temps de m'y consacrer dans l'immédiat. Mais si l'un de vous (ou les deux) souhaite se lancer, je veux bien participer. On pourrait ouvrir un projet commun :
- dans le bugtracker pour référencer ce qu'il y a lieu de faire, donner les priorités et définir qui fait quoi.
- dans svn pour partager nos travaux respectifs.

Avis ?

Euh... eh bien, oui, pourquoi pas :-/ ... tant que je n'y consacre aucun temps !!

Non, je rigole. Non mais je veux dire que j'ai vraiment du boulot qui traîne en ce moment... [extension by LucMorizur] Event Cats n'a pas beaucoup avancé, alors que j'ai fait des promesses... c'est difficile d'en faire d'autres...

Mais bon, sinon, on n'avancera jamais. OK. Allons-y.

Pour commencer, il y a déjà [Bugtracker] ticket 1835.

Tant qu'on y est, envisage-t-on le support des accents, voir [Forum, post 146466 by LucMorizur in topic 17946] Sensibilité à la casse dans "le core" ?

LucMorizur a écrit:

Euh... eh bien, oui, pourquoi pas :-/ ... tant que je n'y consacre aucun temps !!

Non, je rigole. Non mais je veux dire que j'ai vraiment du boulot qui traîne en ce moment... [extension by LucMorizur] Event Cats n'a pas beaucoup avancé, alors que j'ai fait des promesses... c'est difficile d'en faire d'autres...

Mais bon, sinon, on n'avancera jamais. OK. Allons-y.

A la bonne heure ;-)

A nous trois, selon nos dispo de chacun et nos compétences, on arrivera bien à pondre quelque chose qui tienne la route ^^

LucMorizur a écrit:

Pour commencer, il y a déjà [Bugtracker] ticket 1835.

Euh, non. Laissons à César ce qui lui revient de droit. Un bug ou une demande d'évolution de Piwigo reste à Piwigo. Je vais créer un dépot SVN et demander un projet dans le bugtracker propre au projet. D'ailleurs, il faudra d'abord lui trouver un petit nom sympa.

LucMorizur a écrit:

Tant qu'on y est, envisage-t-on le support des accents, voir [Forum, post 146466 by LucMorizur in topic 17946] Sensibilité à la casse dans "le core" ?

Je suis pour. Qui peut le plus...

Whiler a écrit:

Donc j'imagine :
- dans l'admin du plugin :
  - Sensibilité à la casse : On/Off (checkbox)
  - Accents ignorés : On/off

Ok.
+ 1 bouton d'exécution du contrôle d'intégrité des usernames
+ 1 espace dédié pour l'affichage du résultat du contrôle avec possibilité à l'admin de corriger / modifier les logins en cause (?). J'ajouterai aussi la possibilité de notifier par mail les users dont le login a été modifié de la sorte.

Whiler a écrit:

Les paramètres du plugin doivent être stockés où ? (dans le sample que j'avais trouvé, il crée un fichier dat local.. mieux vaut le mettre dans la table config, ailleurs ?)

Je serai plus favorable à une entrée dans la table #_config. Plus simple à gérer, logiquement sauvegardé dans les dumps MySql et sécurisé.

Whiler a écrit:

Je peux bosser sur cette partie pour commencer...
Ensuite, en fonction de ces valeurs (on/off), effectuer les tests pour détecter les pb en base (doublon qd insensible pour les afficher en rouge (array_push($page["errors"] ...)

Jusque là, les machins au chocolat devrait pas trop m'embêter.. ;o)

:-))
Mais avant tout, il lui faut un petit nom à ce projet ! Sinon, pas de dépot SVN ni de bugtracker...
J'ai en tête l'acronyme LCS pour Login Case Sensitiv. Court, précis, facile à retenir et à comprendre. Vos avis ?

Eric a écrit:

LucMorizur a écrit:

Pour commencer, il y a déjà [Bugtracker] ticket 1835.

Euh, non. Laissons à César ce qui lui revient de droit. Un bug ou une demande d'évolution de Piwigo reste à Piwigo. Je vais créer un dépot SVN et demander un projet dans le bugtracker propre au projet.

Oui, évidemment.

Eric a écrit:

LucMorizur a écrit:

Tant qu'on y est, envisage-t-on le support des accents, voir [Forum, post 146466 by LucMorizur in topic 17946] Sensibilité à la casse dans "le core" ?

Je suis pour. Qui peut le plus...

Super ! J'en connais un (ainsi qu'une certaine Béatrice) à qui ça fera plaisir !

Eric a écrit:

Whiler a écrit:

Donc j'imagine :
- dans l'admin du plugin :
  - Sensibilité à la casse : On/Off (checkbox)
  - Accents ignorés : On/off

Ok.
+ 1 bouton d'exécution du contrôle d'intégrité des usernames
+ 1 espace dédié pour l'affichage du résultat du contrôle avec possibilité à l'admin de corriger / modifier les logins en cause (?). J'ajouterai aussi la possibilité de notifier par mail les users dont le login a été modifié de la sorte.

Pfiou ! Ça fait déjà pas mal !

Eric a écrit:

Whiler a écrit:

Les paramètres du plugin doivent être stockés où ? (dans le sample que j'avais trouvé, il crée un fichier dat local.. mieux vaut le mettre dans la table config, ailleurs ?)

Je serai plus favorable à une entrée dans la table #_config. Plus simple à gérer, logiquement sauvegardé dans les dumps MySql et sécurisé.

+1, a priori il n'y a pas énormément de données à stocker.

Whiler a écrit:

Je peux bosser sur cette partie pour commencer...

+1 :-)) !

Whiler a écrit:

Ensuite, en fonction de ces valeurs (on/off), effectuer les tests pour détecter les pb en base (doublon qd insensible pour les afficher en rouge (array_push($page["errors"] ...)

Jusque là, les machins au chocolat devrait pas trop m'embêter.. ;o)

les machins au chocolat ?...

Eric a écrit:

Mais avant tout, il lui faut un petit nom à ce projet ! Sinon, pas de dépot SVN ni de bugtracker...
J'ai en tête l'acronyme LCS pour Login Case Sensitiv. Court, précis, facile à retenir et à comprendre. Vos avis ?

LCAS, Login Case & Accents Sensitivity ?

Whiler a écrit:

ok... vas falloir que j'en épluche du plugin pour voir comment tout ça fonctionne ;o)) mais j'ai pas peur ;o)

Bravo !

Moi non plus, je n'avais pas peur avant mon premier plugin... maintenant, si :-/ ...

;-)

Whiler a écrit:

Eric a écrit:

Mais avant tout, il lui faut un petit nom à ce projet ! Sinon, pas de dépot SVN ni de bugtracker...

Il faut que je crée un user qq part.. pour le moment, je ne suis enregistré que sur le forum...

Sur Mantis par exemple ?

En attendant, voici un premier draft de ce à quoi cela pourrait ressembler : LCAS

La galerie doit être en français (je n'ai pas encore traduit les strings de la version anglaise).

Le code ne fait pas encore ce qu'il devra faire (j'affiche tous les utilisateurs... pas seulement ceux qui poseront un problème.. mais bon, ça c'est pas le plus dur à coder)...

Cela a été fait à la va-vite... ce qui signifie que j'ai une tonne de refactoring à faire pour que les variables aient un vrai nom, pour la localisation, comme pour le reste...

Toute ressemblance avec un plugin déjà existant ne serait que pur hasard, tant au niveau du look&feel que du code...

Si ça vous convient, j'avancerai un peu davantage... si des personnes suspectent que je n'ai pas inventé le code, on essayera de voir pour faire autrement ;o)

N'hésitez pas à remonter vos impressions...