Eric a écrit:
(...) Luc, si tu as 5 minutes pour tester chez toi pour nous départager ;-))
Whiler a écrit:
(...) Luc... une idée ? un truc qui nous aurait échappé ?
Désolé, vraiment pas eu le temps de me connecter aujourd'hui... et ce soir, c'est concert de Noël des gamins...
Demain soir je regarde vos avancées !
Hors ligne
Whiler a écrit:
Luc.. c'est dans ta méthode ;oppp
Mais non, j'dis pas ça pour me dédouaner ;o)
M'enfin, j'ai rien fait ?! ;-)
Hors ligne
Whiler a écrit:
Eric, ce n'est pas lié à ton environnement.. le S pose problème...
Pourtant, dans le tableau, il est présent et a la bonne valeur.. (j'ai vérifié en hexa... x53)
Sophie et sophie ont un soucis... la faute à Béatrice ?
Oui, j'étais en train de tester différents cas de figure et c'est bien le "S" qui est en cause. Reste à trouver pourquoi.
Je vais déclarer forfait moi aussi pour aujourd'hui. Suite des aventures demain ;-)
Hors ligne
Whiler a écrit:
Deux valeurs pour une même clé ! Forcément.. la seconde gagnait... et comme on ne sert pas souvent du ſ....
Problème résolu.. permission accordée, vous pouvez sortir ;o)
Oups !
Merci Whiler. Et Eric !
Hors ligne
Whiler a écrit:
Deux valeurs pour une même clé ! Forcément.. la seconde gagnait... et comme on ne sert pas souvent du ſ....
Problème résolu.. permission accordée, vous pouvez sortir ;o)
En effet, il y avait bien un ver (un bug) à cet endroit-là, c'est corrigé aussi dans http://lucmorizur.free.fr/test2.php et http://lucmorizur.free.fr/test2_en.php .
Par contre, avec la dernière version de LCAS, sur ma galerie dernière version en local (Win XP 32, FF 3.6, WampServer 2), après avoir placé $conf['insensitive_case_logon'] à true et activé l'insensibilité à la casse dans LCAS, si j'essaie avec "Test1/1234" (casse correcte), je suis identifié ; si j'essaie avec "test1/1234", ça marche pas :-( .
Je vais essayer de mettre ça sur ma galerie de tests avant le repas ;-)
Hors ligne
LucMorizur a écrit:
Par contre, avec la dernière version de LCAS, sur ma galerie dernière version en local (Win XP 32, FF 3.6, WampServer 2), après avoir placé $conf['insensitive_case_logon'] à true et activé l'insensibilité à la casse dans LCAS, si j'essaie avec "Test1/1234" (casse correcte), je suis identifié ; si j'essaie avec "test1/1234", ça marche pas :-( .
Je vais essayer de mettre ça sur ma galerie de tests avant le repas ;-)
Bon, pareil sur http://lucmorizur.free.fr : Test111/1234 OK ; test111/1234 NOK.
Mais, heu... j'ai lu qu'en diagonale vos autres posts récents... je vais quand même y jeter un coup d'œil dans la soiré, y'a peut-être une explication... et puis, j'voulais aussi dire d'autres trucs, mais moins importants.
À plus !
Hors ligne
Heu... ben parce que LCAS n'est pas encore codé peut-être ;o))
Moi, j'ai fait la partie admin... mais il n'y a encore aucun hook en place...
Ce que tu peux tester, c'est de créer plusieurs users avec le même pseudo (à la casse/accent près...)
Pour tester l'administration des doublons...
Si tu regardes les captures des posts précédents tu verras des exemples (avec l'interface à onglets qui a disparu depuis...)
Hors ligne
Les "trucs moins importants" :
Eric a écrit:
A mon avis, on ne peut / doit pas passer outre les options intégrés à Piwigo mais s'adapter en fonction de leur position.
+ beaucoup. Tout-à-fait d'accord, c'était bien ce que je voulais dire dans [Forum, post 158753 by LucMorizur in topic 19180] Insensible à la casse....
Eric a écrit:
De fait, on aura plusieurs aspects:
1- L'option $conf['insensitive_case_logon'] = false (valeur par défaut) -> Il n'y a aucune raison pour qu'on restreigne l'identification à la casse puisque les users pourront s'inscrire avec la casse qu'ils veulent. Cela apporterait plus de problèmes qu'autre chose.
2- L'option $conf['insensitive_case_logon'] = false (valeur par défaut) et on veut pouvoir contrôler les accents à l'identification -> Activation de l'option idoine du plugin mais toujours aucun intérêt à activer le contrôle de casse.
3- L'option $conf['insensitive_case_logon'] = true -> On peut proposer d'utiliser l'un et/ou l'autre des options du plugin sans distinction.
OK.
Eric a écrit:
Le tout est de savoir si on met en place un moyen de modifier la valeur de $conf['insensitive_case_logon'] directement sur la page d'admin du plugin ou non. Cette valeur sera alors inscrite dans le fichier ./local/config/config.inc.php...
Je sais pas vraiment. Je pense que le fait de l'activer depuis le plugin peut être pas mal.
Ce qui est important :
ben il semble que ce soit normal, que ça ne fonctionne pas, les fonctionnalités principales sont désactivées ( http://piwigo.org/dev/browser/extension … v=8192#L57 ), non ? (Désolé, je prends vraiment le train en marche :-/ ...) Et sinon, je ne vois pas où est utilisée la fonction LCAS_change_case , en fait ? Car au moment de l'identification (lorsqu'elle est prise en charge par LCAS), ce sont des LOWER (en DB) et strtolower (en PHP) qui sont utilisés ?
Bon, à bientôt !
Hors ligne
Whiler a écrit:
Heu... ben parce que LCAS n'est pas encore codé peut-être ;o))
Moi, j'ai fait la partie admin... mais il n'y a encore aucun hook en place...
Ce que tu peux tester, c'est de créer plusieurs users avec le même pseudo (à la casse/accent près...)
Pour tester l'administration des doublons...
Si tu regardes les captures des posts précédents tu verras des exemples (avec l'interface à onglets qui a disparu depuis...)
OK, c'est ce que j'ai vu effectivement.
La suite demain soir !
Hors ligne
LucMorizur a écrit:
Eric a écrit:
Le tout est de savoir si on met en place un moyen de modifier la valeur de $conf['insensitive_case_logon'] directement sur la page d'admin du plugin ou non. Cette valeur sera alors inscrite dans le fichier ./local/config/config.inc.php...
Je sais pas vraiment. Je pense que le fait de l'activer depuis le plugin peut être pas mal.
Ou alors faire en sorte que les options du plugin ne soient pas accessibles si $conf['insensitive_case_logon'] = false.
LucMorizur a écrit:
ben il semble que ce soit normal, que ça ne fonctionne pas, les fonctionnalités principales sont désactivées ( http://piwigo.org/dev/browser/extension … v=8192#L57 ), non ? (Désolé, je prends vraiment le train en marche :-/ ...) Et sinon, je ne vois pas où est utilisée la fonction LCAS_change_case , en fait ? Car au moment de l'identification (lorsqu'elle est prise en charge par LCAS), ce sont des LOWER (en DB) et strtolower (en PHP) qui sont utilisés ?
Pour l'heure, je ne fais pas encore appel à la fonction LCAS_change_case. Je cherche d'abord à intercepter le process d'identification et à influer sur le comportement. Utiliser un fonction de requête simple avec LOWER et strtolower me permet de tracer le comportement des diverses variables.
Malheureusement, si j'arrive à intercepter le process, je n'arrive pas encore à influer sur le comportement. L'identification de Piwigo fait appel à la fonction try_log_user() qui propose 2 triggers "login_success" et "login_failure". Le problème est que ces triggers ne conditionnent pas l'identification mais permette d'ajouter des actions après que l'identification ait réussi ou échoué.
Tout çà pour dire que, pour l'instant, je sèche... Mais je ne désespère pas ;-)
Hors ligne
Eric a écrit:
LucMorizur a écrit:
Je sais pas vraiment. Je pense que le fait de l'activer depuis le plugin peut être pas mal.
Ou alors faire en sorte que les options du plugin ne soient pas accessibles si $conf['insensitive_case_logon'] = false.
Oui, +1.
Une autre réflexion, à exploiter plutôt lorsque l'on sera plus avancés, mais bon je l'expose quand même maintenant : le "core" de Piwigo ne propose pour le moment l'insensibilité à la casse qu'à l'inscription. Ce comportement est à modifier, comme l'a indiqué plg sur le forum anglophone. Mais la méthode utilisée dans le "core" de Piwigo pour l'insensibilité à la casse, n'utilise pas la fonction LCAS_change_case, qu'on peut légitimement trouver peut-être un peu lourde ? Je pense donc que nous devons :
_ résoudre le [Bugtracker] ticket 1835 en utilisant les mêmes méthodes que le "core" de Piwigo, pour les cas où $conf['insensitive_case_logon'] = false ;
_ proposer une insensibilité à la casse "renforcée" (utilisant donc LCAS_change_case , ou toute autre fonction mieux écrite) lorsque $conf['insensitive_case_logon'] = true ;
_ proposer une insensibilité aux accents lorsque $conf['insensitive_case_logon'] = true .
Si vous êtes d'accord. (Et ce questionnement ne s'adresse pas forcément qu'à Eric et Whiler ;-) .)
LucMorizur a écrit:
ben il semble que ce soit normal, que ça ne fonctionne pas, les fonctionnalités principales sont désactivées
Non mais j'suis vraiment à l'ouest ; pour le moment dans la version "publiée" on étudie déjà la liste des username qui pourraient poser problème :-/ ...
Eric a écrit:
Pour l'heure, je ne fais pas encore appel à la fonction LCAS_change_case. Je cherche d'abord à intercepter le process d'identification et à influer sur le comportement. Utiliser un fonction de requête simple avec LOWER et strtolower me permet de tracer le comportement des diverses variables.
OK.
Eric a écrit:
Malheureusement, si j'arrive à intercepter le process, je n'arrive pas encore à influer sur le comportement. L'identification de Piwigo fait appel à la fonction try_log_user() qui propose 2 triggers "login_success" et "login_failure". Le problème est que ces triggers ne conditionnent pas l'identification mais permette d'ajouter des actions après que l'identification ait réussi ou échoué.
Tout çà pour dire que, pour l'instant, je sèche... Mais je ne désespère pas ;-)
"après que l'identification a réussi ou échoué" : "après que" => indicatif ;-)
Serait-il possible de recommencer un try_log_user() après qu'une identification a échoué ?
Dernière modification par LucMorizur (2010-12-19 15:11:25)
Hors ligne