petite ()

est ce que vous avez bien a l'esprit l'utilisation par certain de l'identification externe ?

ddtddt a écrit:

petite ()

est ce que vous avez bien a l'esprit l'utilisation par certain de l'identification externe ?

T'as un pointeur ?
Personnellement, non, j'n'savais même pas que cette option existait...
C'est basé sur plusieurs trucs (ldap, google, ...) ?

Concernant ce topic, ce n'est pas gênant, puisque l'on est sur une extension qui ne sera clairement pas installée par ceux qui utilisent ce mécanisme ;o) (par contre.. pour une éventuelle intégration au core... il suffira de ne pas l'activer dans ce contexte ;op)

Dernière modification par Whiler (2011-01-05 12:12:38)

Whiler a écrit:

Personnellement, non, j'n'savais même pas que cette option existait...
C'est basé sur plusieurs trucs (ldap, google, ...) ?

Non, pas de LDAP mais possibilité d'authentification Apache ou via une table d'utilisateurs externe à Piwigo, moyennant mappage des champs.

Whiler a écrit:

Si c'est basé sur une authentification apache... le trigger qui va bien ne serait  pas déclenché et donc LCAS, actif ou non serait tout simplement ignoré ?

Non car LCAS ne s'appuie pas sur un trigger à l'identification mais surcharge le fichier identification.php qui est commun à tout type d'authentification (interne, externe et Apache). Mais j'avoue ne pas maitriser le fonctionnement de l'authentification Apache.

Pour l'authentification sur table externe (autre CMS par exemple), après réflexion, LCAS ne devrait pas poser de problème sauf si le CMS en question ne gère pas les casses et accents. Par exemple, si Piwigo s'appuie sur la table users de Joomla (les création de comptes se font donc via Joomla) et que Joomla ne gère pas les casses et accents des users qui s'inscrivent, on va avoir des problèmes...

D'où ma position de ne pas activer LCAS dans ces cas (ajouter un contrôle à l'activation du plugin sur les $conf concernées ?).

Bonsoir ;

bon, pas mal de choses de ma part ce soir, mais surtout niveau discussion ; pour ce qui est du code ce n'est pas énorme en termes de fonctionnalités. Malgré tout j'ai fait une livraison :

[Subversion] r8565

* [Bugtracker] ticket 2100
En fait à l'origine, lorsque j'ai codé la fonction aujourd'hui utilisée sous le nom de LCAS_change_case dans LCAS, j'utilisais la variable $lang car je voulais qu'un webmestre voulant utiliser cette fonctionnalité, mais dans une autre langue que celles écrites en Grec, Latin ou Cyrillique, puisse ajouter une table de remplacement de caractères, adaptée à sa langue. Ou bien aussi qu'il puisse corriger d'éventuelles erreurs des tables d'origine. En fait utiliser $lang est idiot, car cette fonctionnalité est indépendante de la langue. Néanmoins je voudrais garder cette possibilité, et que le rajout de la table en question puisse être fait via LocalFiles Editor. D'où mise en place des tables en question sur $conf.

Ce que j'aimerais bien maintenant, c'est donner la possibilité au webmestre de visualiser les tables en questions, ce pourquoi j'ai externalisé ces tables dans un fichier à part, lequel est appelé par un include() dans LCAS_change_case. Il ne s'agit que de visualiser, afin de pouvoir copier-coller dans ./local/config/config.inc.php via LocalFiles Editor.

Qu'en pensez-vous, êtes-vous d'accord ?

Cela implique par contre un changement sur l'interface d'administration, car il faudrait proposer au webmestre :

  o Casse et accents sensibles (plugin désactivé)
  o Insensibilité à la casse
  o Insensibilité aux accents
  o Insensibilité à la casse et aux accents
  o Table personnalisée (voir tables d'origine)

Dans ces boutons d'option, le dernier cas ne serait sélectionnable que s'il existe $conf['LCAS_replacement_set'][0] . Le "voir tables d'origine" serait un lien vers un nouvel onglet dans LCAS, qui afficherait le contenu du fichier LCAS_replacement_set.inc.php que j'ai rajouté dans ma livraison, lequel est déjà conçu pour être le plus pédagogique possible dans l'optique de rajouter une table.

Voilivoilou ; par contre comme je n'ai pas du tout participé à la mise en place de l'interface d'admin, ainsi qu'à la gestion du stockage des options choisies en BDD, je ne me suis pas aventuré à modifier cette partie-là :-/ ... si cette fonctionnalité vous plaît, pourriez-vous vous en occuper svp ? :-/ ...........



* un peu de nettoyage de code

Whiler a écrit:

Avant :     Béa BÉATRICE
Après :     béa béatrice
strtolower :     béa bÉatrice
mb_strtolower (ISO-8859-1) :     béa béatrice
LucMorizur: 0.00103 s.
strtolower: 0.00001 s.
mb_strtolower: 0.00004 s.

Eh oui :-/ ... deux "foreach" imbriqués sur un tableau de plus de cent lignes dans le meilleur des cas...
J'ai donc retiré la capacité à $Username dans LCAS_change_case($Username, $Option) , d'être un tableau. Je ne suis pas sûr que ça soit notable sur l'efficacité du code -_- ... mais bon, a priori ce ne sera jamais utilisé autrement de toutes façons.


Bon ; sinon :

ddtddt a écrit:

petite ()

est ce que vous avez bien a l'esprit l'utilisation par certain de l'identification externe ?

Euh, non, pas du tout en ce qui me concerne.
Excellente question ddtddt, merci de l'avoir posée |-( ...
;-)
Ben en fait :
_ dans le cas d'une authentification Apache, si j'ai bien compris la chose, les identifiants et mots de passe sont stockés dans un fichier .htpasswd => rien à voir avec le PHP de Piwigo, donc LCAS inactif. Correct ?
_ pour ce qui est d'une "identification externe", là, tout dépend de savoir où est située la table des identifiants et mots de passe, non ? En tous cas si ce n'est pas celle de Piwigo, de toutes façons => plouf.

Eric a écrit:

A mon sens, LCAS ne peut / doit pas être utilisé dans ces cas de figure.

+1

Whiler a écrit:

LucMorizur a écrit:

[Subversion] r8475

S'il y a ambiguïté entre certains comptes (existence de Test1 ET de TEST1 avant l'activation de LCAS), les comptes en question ne seront identifiés que s'ils respectent totalement leur casse et/ou accentuation. Par contre les autres comptes ne provoquant pas d'ambiguïté, bénéficieront de l'insensibilité à la casse et/ou aux accents mise(s) en place par LCAS.

On tombe dans ce cas là ?

A priori telle que je comprends la discussion, la question de Whiler est liée au questionnement précédent, sur "l'identification externe". Si c'est bien le cas, je ne sais pas répondre à la question :-/ .


Voilà ; ensuite, je pense regarder les cas de contrôle à l'enregistrement.

À bientôt !

Dernière modification par LucMorizur (2011-01-10 13:31:22)

Salut Luc,

J'avoue ne pas trop comprendre où tu veux en venir. :-/

LucMorizur a écrit:

o LCAS inactif, insensibilité à la casse | casse sensible : $conf['insensitive_case_logon'] = true | false
  o Insensibilité à la casse (plus complète que par défaut)
  o Insensibilité aux accents
  o Insensibilité à la casse et aux accents
  o Table personnalisée (voir tables d'origine)

Avec, sur la première ligne, insensibilité à la casse et casse sensible ; et true et false affichés en fonction de l'état de $conf['insensitive_case_logon'] ; et toutes les autres options grisées, et donc la première sélectionnée par défaut, si $conf['insensitive_case_logon'] vaut false.

A mon sens, si $conf['insensitive_case_logon'] = false, le plugin ne devrait même pas pouvoir s'activer (idem si la galerie utilise une authentification externe ou Apache). Un message d'explication dans l'erreur d'activation devrait suffire au webmestre pour s'orienter vers LocalFiles Editor et faire les modifications qui s'imposent avant de retenter l'activation.

J'ai commencé à traiter le sujet dans [Bugtracker] ticket 2099 mais c'est malheureusement mon tour de manquer cruellement de disponibilité...

Dans le cas "Insensibilité à la casse et aux accents", il suffit d'activer simultanément les deux options précédentes. Pourquoi faire plus complexe ? D'autant qu'il faudrait alors transformer les contrôles d'options (olives vs cases à cocher) et tester les valeurs de chacune pour éviter les conflits ou les incompréhensions des webmestres. Par exemple:
- Si Insensibilité à la casse = On alors Insensibilité aux accents = Off et Insensibilité à la casse et aux accents = Off
- Si Insensibilité aux accents = On alors Insensibilité à la casse = Off et Insensibilité à la casse et aux accents = Off
- Si Insensibilité à la casse et aux accents = On alors Insensibilité à la casse = Off et Insensibilité aux accents = Off
...

Bref un peu compliqué pour un résultat pas forcément plus clair pour les webmestres, non ? D'expérience, avec UAM, je pense qu'il faut cibler la simplification au maximum et mettre en avant les différences entre les contrôles à l'identification et à l'inscription (à l'inscription actuellement traitée en partie par Piwigo).

Maintenant, comme dit au début, je cerne mal ton but et peut-être n'ai-je rien compris à ta démarche ;-)

Ok ! Je n'avais pas compris que les "o" étaient des olives (boutons d'option) et que tu voulais ajouter un tableau de correspondance personnalisable. :-)

Avec ces explications, je ne peux que "plussoyer". Toutefois, je ne sais pas comment tu vois la chose pour le stockage de cette nouvelle table de correspondances personnalisable mais je pense qu'une table de bdd dédiée serait bien. Quelque chose comme #_LCAS_ConvertionTable ?

Eric a écrit:

Toutefois, je ne sais pas comment tu vois la chose pour le stockage de cette nouvelle table de correspondances personnalisable mais je pense qu'une table de bdd dédiée serait bien. Quelque chose comme #_LCAS_ConvertionTable ?

Oups, mille pardons : j'emploie le même mot pour deux choses différentes :-/ ... à savoir, le mot "table" pour à la fois les tableaux définis dans le PHP (variables de type array() ), et les tables définies dans la BDD... tsss....

Or donc, j'ai l'intention de permettre au webmestre de se définir son tableau personnalisé de correspondance de caractères... si ça vous va...