•  » Plugins
  •  » Insensible à la casse...

#1 2010-12-11 03:04:51

Whiler
Membre
Clichy
2004-12-24
189

Insensible à la casse...

Bonjour,

J'ai ajouté la ligne suivante,

Code:

$conf['insensitive_case_logon'] = true;

via le plugin LocalFiles Editor dans le fichier local/config/config.inc.php

Malgré cela, j'obtiens le message •Mot de passe invalide ! lorsque je ne respecte pas la casse du nom de l'utilisateur... si je respecte la casse, j'arrive à m'authentifier...
(le mot de passe est tapé avec la bonne casse dans les deux tests)

J'utilise la version 2.1.5 et j'ai quelques plugins d'activés :
    * BBCode Bar
    * Captcha
    * Charlies'
    * Contact Form
    * Cumulus Tags Cloud
    * Delete Hit
    * DynaRecePerio
    * EDIT Maps & Earth
    * LocalFiles Editor
    * Maps & Earth
    * Piwigo AutoUpgrade
    * Smilies Support

Une idée de la cause du problème ? ou comment investiguer ? des fichiers ou données à vérifier/modifier ?

Lors de précédents tests, j'ai essayé en ajoutant une nouvelle ligne à la table des configurations, *_config, avec pour valeurs : insensitive_case_logon, true, NULL
Ainsi que de modifier le fichier config_default.inc.php, mais sans plus de succès...

Merci,

  W.

Hors ligne

#2 2010-12-11 03:30:40

Whiler
Membre
Clichy
2004-12-24
189

Re: Insensible à la casse...

Whiler a écrit:

Lors de précédents tests, j'ai essayé en ajoutant une nouvelle ligne à la table des configurations, *_config, avec pour valeurs : insensitive_case_logon, true, NULL
Ainsi que de modifier le fichier config_default.inc.php, mais sans plus de succès...

J'ai supprimé la ligne de la base de données depuis et remis à false la valeur dans config_default.inc.php

Bien sûr, j'ai laissé à true dans local/config/config.inc.php.

Dans les options de maintenance, j'ai également cliqué sur :
    * Réparer et optimiser la base de données
    * Purger les sessions
    * Purger les templates compilés

Sans succès pour l'instant...

Hors ligne

#3 2010-12-11 03:35:59

Eric
Équipe Piwigo
VALENCE (FR)
2005-03-25
4579

Re: Insensible à la casse...

Le contrôle de la casse s'entend sur le login au moment de  l'inscription. L'option $conf['insensitive_case_logon'] ne s'applique donc qu'aux logins lors d'une tentative d'inscription. Par exemple :

Si $conf['insensitive_case_logon'] = True et si un utilisateur ayant pour login "test" est déjà inscrit, les [/u]futures inscriptions[/u] avec les logins "Test", "TEST" ou "TEst" (etc...) échoueront.

Ceci est un comportement normal. Ce qui l'est moins c'est la sensibilité à la casse sur l'identification : Si un compte "test" existe, on peut normalement s'identifier avec "TEST" ou "TEst" (etc...). Il n'y a pas (encore) de contrôle de la casse à ce niveau et c'est l'objet du [Forum, topic 17946] Sensibilité à la casse dans "le core".

Dans ton cas, il y a visiblement un pb ailleurs. Comme préconisé précédemment, commences par purger tes insertions dans la table #_config. Ensuite, faire des tests en désactivant séquentiellement les plugins actifs. Si le pb persiste, on creusera du côté du core de Piwigo.

Hors ligne

#4 2010-12-11 04:00:36

Whiler
Membre
Clichy
2004-12-24
189

Re: Insensible à la casse...

Eric a écrit:

Le contrôle de la casse s'entend sur le login au moment de  l'inscription. L'option $conf['insensitive_case_logon'] ne s'applique donc qu'aux logins lors d'une tentative d'inscription. Par exemple :

Si $conf['insensitive_case_logon'] = True et si un utilisateur ayant pour login "test" est déjà inscrit, les [/u]futures inscriptions[/u] avec les logins "Test", "TEST" ou "TEst" (etc...) échoueront.

Ceci est un comportement normal. Ce qui l'est moins c'est la sensibilité à la casse sur l'identification : Si un compte "test" existe, on peut normalement s'identifier avec "TEST" ou "TEst" (etc...). Il n'y a pas (encore) de contrôle de la casse à ce niveau et c'est l'objet du [Forum, topic 17946] Sensibilité à la casse dans "le core".

Dans ton cas, il y a visiblement un pb ailleurs. Comme préconisé précédemment, commences par purger tes insertions dans la table #_config. Ensuite, faire des tests en désactivant séquentiellement les plugins actifs. Si le pb persiste, on creusera du côté du core de Piwigo.

ce nom d'utilisateur est déjà pris

Ok... donc.. en fait... pour résumer, j't'ai fait perdre ton temps à chercher un problème où il n'y en avait pas vraiment, puisque ce n'est pas lié à mon installation/configuration, mais à un problème connu...

Lors de l'enregistrement (inscription), c'est bien géré...

Et donc, maintenant que j'ai quitté le thread UAM, j'vais pouvoir en parler ici en disant que tu as supprimé cette option parce que doublon alors qu'en fait, ce n'était pas un doublon puisqu'il fonctionnait comme je le souhaitais...

C'était super lourd à surcharger (qd c'était dans UAM) pour la connexion ou ça se fait en quelques lignes ? (en clair, si t'as la dernière version qui le supportait, j'suis preneur pour essayer de la désosser (pour ne pas surcharger ce que l'actuel UAM fait) et me patcher mon install via un plugin pour éviter de modifier les sources... (tu m'as déjà pris en flag en modifiant mon config_default.inc.php, alors j'vais pas recommencer ;o)))

Sinon, pour moi, un accent est différent d'un caractère non accentué ;o)

Hors ligne

#5 2010-12-11 12:27:44

Eric
Équipe Piwigo
VALENCE (FR)
2005-03-25
4579

Re: Insensible à la casse...

[HS] J'ai trouvé un "couche plus tard" que moi ! Dernier message à 4h00, je ne crois pas avoir jamais été jusque là... Sur le forum, j'entends ! Lors de mes noubas de jeunesse (soupir !), j'arrivais souvent à faire le tour du cadran ;-) [/HS]

Sinon, après une bonne nuit de réflexion, j'en arrive à deux approches:
- Réintégrer dans UAM un contrôle sur la casse à l'identification pour la prochaine version.
- Prendre en charge le [Bugtracker, ticket 1835, fixed] Username case sensitivity et le résoudre pour qu'il soit intégré dans la prochaine version de Piwigo (à voir avec le reste de l'équipe si c'est ok).

Dans les 2 cas, il faudra patienter un peu...

Hors ligne

#6 2010-12-11 12:35:15

Whiler
Membre
Clichy
2004-12-24
189

Re: Insensible à la casse...

;o)) Mais non.. j'avais programmé un CRON pour poster les messages à cette heure-là ;o)

Plus sérieusement, comme tu l'as dit sur l'autre thread, il est évident que la seconde solution semble être la meilleure... (si l'équipe est d'accord...)

Dans tous les cas, merci beaucoup pour tes réponses !

Hors ligne

#7 2010-12-11 14:49:42

LucMorizur
Membre
Vienne (Isère, 38)
2009-03-01
1969

Re: Insensible à la casse...

Eric a écrit:

- Prendre en charge le [Bugtracker, ticket 1835, fixed] Username case sensitivity et le résoudre pour qu'il soit intégré dans la prochaine version de Piwigo (à voir avec le reste de l'équipe si c'est ok).

+1 !

Eric a écrit:

Dans les 2 cas, il faudra patienter un peu...

No souci.

Merci à tous les deux :-)

Hors ligne

#8 2010-12-11 15:38:47

Eric
Équipe Piwigo
VALENCE (FR)
2005-03-25
4579

Re: Insensible à la casse...

La sensibilité ou l'insensibilité à la casse pour les logins (que ce soit à l'inscription ou à l'identification) est une notion qui me parait particulièrement pénible à cerner... Question de câble du cerveau ?

Quoi qu'il en soit, je détecte une incohérence dans le système actuel : Sur mes galeries, quelque soit la valeur true ou false de $conf['insensitive_case_logon'], je ne peux pas inscrire deux utilisateurs "test" et "TEST". A chaque fois, j'ai le message "ce nom d'utilisateur est déjà pris". Ce qui est anormal si $conf['insensitive_case_logon'] = false.

@LucMorizur et Whiler : Pourriez-vous confirmer ou infirmer ce fait ?

Hors ligne

#9 2010-12-11 16:39:01

Eric
Équipe Piwigo
VALENCE (FR)
2005-03-25
4579

Re: Insensible à la casse...

Laissez tomber ma question sur le post précédent : L'erreur venait de chez moi...

J'ai réfléchi à la problématique et j'ai peur que cela soit un peu plus complexe à gérer. Voici mon analyse:

Cas 1: $conf['insensitive_case_logon'] = false
   * On peut s'inscrire sans problème avec les couples utilisateurs/mot de passe suivant: test/pwd1, Test/pwd2 ou TEST/pwd3
   * A l'identification, on aura logiquement:
           - test/pwd2 ou test/pwd3 = NOK
           - test/Pwd1 = OK
           - Test/pwd1 ou Test/pwd3 = NOK
           - Test/pwd2 = OK
           etc...

    Ceci est, à mon sens le fonctionnement normal attendu si on ne contrôle pas la casse du login.

Cas 2: $conf['insensitive_case_logon'] = true
   * On ne peut pas s'inscrire avec les couples utilisateurs/mot de passe suivant: test/pwd1, Test/pwd2 ou TEST/pwd3 et on aura à chaque fois le message "ce nom d'utilisateur est déjà pris". Seul test/pwd1 est possible.
   * A l'identification, on aura :
           - test/pwd2 ou test/pwd3 = NOK -> Correct
           - test/Pwd1 = OK -> Correct
           - Test/pwd1 ou TEST/pwd1 = NOK -> Incorrect !!

    A l'identification, si $conf['insensitive_case_logon'] = true, le login devrait être insensible à la casse. Cà, on peut le corriger assez facilement.

Là où çà se complique c'est lorsqu'une galerie, étant précédemment avec $conf['insensitive_case_logon'] = false (cas 1), change de config avec $conf['insensitive_case_logon'] = true (cas 2). Il y a un risque probable que nous ayons plusieurs comptes avec le même login mais en casse différente (test/pwd1, Test/pwd2 ou TEST/pwd3) ce qui est contre la logique du cas 2.

On se retrouve donc avec une incohérence majeur puisque on est sensé ne trouver qu'un seul compte test=Test=TEST/pwd1 alors que nous en avons 3 !! Comment gérer cela ?

Hors ligne

#10 2010-12-11 17:57:16

Whiler
Membre
Clichy
2004-12-24
189

Re: Insensible à la casse...

Entièrement d'accord avec ton analyse...

Personnellement, je le gèrerai ainsi :
- Tout comme t'as dit...

- Si 2 users ne diffèrent que par la casse, l'un des deux fonctionnera.. lequel... m'en fous ;o))

Il serait peut-être plus simple de proposer un menu dans la maintenance qui permettrait d'afficher les users en doublon pour une casse identique... après, libre à l'administrateur de prévenir ses utilisateurs avec un blocage potentiel pour leur demander un nouveau pseudo ?

Hors ligne

#11 2010-12-11 18:32:02

LucMorizur
Membre
Vienne (Isère, 38)
2009-03-01
1969

Re: Insensible à la casse...

Eric a écrit:

J'ai réfléchi à la problématique et j'ai peur que cela soit un peu plus complexe à gérer. Voici mon analyse:

(...)

           - Test/pwd1 ou TEST/pwd1 = NOK -> Incorrect !!

    A l'identification, si $conf['insensitive_case_logon'] = true, le login devrait être insensible à la casse.

Je plussoie, c'était tout-à-fait mon analyse :-)

Eric a écrit:

Là où çà se complique c'est lorsqu'une galerie, étant précédemment avec $conf['insensitive_case_logon'] = false (cas 1), change de config avec $conf['insensitive_case_logon'] = true (cas 2). Il y a un risque probable que nous ayons plusieurs comptes avec le même login mais en casse différente (test/pwd1, Test/pwd2 ou TEST/pwd3) ce qui est contre la logique du cas 2.

On se retrouve donc avec une incohérence majeur puisque on est sensé ne trouver qu'un seul compte test=Test=TEST/pwd1 alors que nous en avons 3 !! Comment gérer cela ?

Je pense qu'il y a beaucoup de façons différentes de gérer ce problème. Le principal, c'est surtout que le webmestre et éventuellement les admins, soient mis au courant. Ensuite, pour choisir la manière, en général c'est celle qui est la moins gourmande en ressources, et la plus efficace.

Sinon une petite idée peut-être un peu bizarre pour patienter en attendant qu'un admin résolve le problème : si il existe sur la galerie test/pwd1 et Test/pwd2, et que $conf['insensitive_case_logon'] passe à true, alors :
_ message au webmestre (à mon avis c'est le courriel qui est le plus efficace) ;
_ en attendant, test/pwd1  -> OK ; Test/pwd2 -> OK ; mais aussi test/pwd2 et Test/pwd1 ! De même d'ailleurs que tEst/pwd1 et tEst/pwd2, teSt/pwd1 et teSt/pwd2... etc. En toute logique, ça ne devrait être préjudiciable à personne...

Hors ligne

#12 2010-12-11 22:11:29

Eric
Équipe Piwigo
VALENCE (FR)
2005-03-25
4579

Re: Insensible à la casse...

Whiler a écrit:

- Si 2 users ne diffèrent que par la casse, l'un des deux fonctionnera.. lequel... m'en fous ;o))

Un peu rapide, le raccourci, non ? ^^

Plu sérieusement :

Whiler a écrit:

Il serait peut-être plus simple de proposer un menu dans la maintenance qui permettrait d'afficher les users en doublon pour une casse identique... après, libre à l'administrateur de prévenir ses utilisateurs avec un blocage potentiel pour leur demander un nouveau pseudo ?

Il s'agirait alors d'ajouter un contrôle d'intégrité supplémentaire qui ne serait pas automatique puisque soumis à l'action d'un admin ou webmaster. Pas vraiment le top...
Surtout que le passage de $conf['insensitive_case_logon'] = false à true est une action manuelle de configuration réservée au webmaster (il me semble -> A confirmer) et qu'il faudrait alors développer un mécanisme de contrôle sur les conf passées dans local/config/config.inc.php et config_default.inc.php. Ce qui est très loin d'être évident (enfin, pour moi).


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 : si il existe sur la galerie test/pwd1 et Test/pwd2, et que $conf['insensitive_case_logon'] passe à true, alors :
_ message au webmestre (à mon avis c'est le courriel qui est le plus efficace) ;

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 ?

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.

Franchement, ce cas est un véritable casse-tête qui aboutirait au mieux à une usine à gaz particulièrement compliquée à intégrer au core de Piwigo.

LucMorizur a écrit:

_ en attendant, test/pwd1  -> OK ; Test/pwd2 -> OK ; mais aussi test/pwd2 et Test/pwd1 ! De même d'ailleurs que tEst/pwd1 et tEst/pwd2, teSt/pwd1 et teSt/pwd2... etc. En toute logique, ça ne devrait être préjudiciable à personne...

Pas trop d'accord avec toi. Techniquement, le compte test/pwd1 ne pourra jamais s'identifier avec test/pwd2. Idem pour toutes les autres variantes de casse pour un même login car il s'agit là de compte d'utilisateurs bien différents.
Tu peux faire des tests sur une galerie "jetable" en modifiant la fonction try_log_user() dans le fichier ../include/functions_user.inc.php (ligne 1143) de manière à avoir ceci:

Code:

/**
 * Tries to login a user given username and password (must be MySql escaped)
 * return true on success
 */
function try_log_user($username, $password, $remember_me)
{
  global $conf;
  if ($conf['insensitive_case_logon'] == true)
  {
  // retrieving the encrypted password of the login submitted
  $query = '
SELECT '.$conf['user_fields']['id'].' AS id,
       '.$conf['user_fields']['password'].' AS password
  FROM '.USERS_TABLE.'
  WHERE LOWER('.$conf['user_fields']['username'].') = \''.pwg_db_real_escape_string(strtolower($username)).'\'
;';
  }
  else
  {
  // retrieving the encrypted password of the login submitted
  $query = '
SELECT '.$conf['user_fields']['id'].' AS id,
       '.$conf['user_fields']['password'].' AS password
  FROM '.USERS_TABLE.'
  WHERE '.$conf['user_fields']['username'].' = \''.pwg_db_real_escape_string($username).'\'
;';
  }
  $row = pwg_db_fetch_assoc(pwg_query($query));
  if ($row['password'] == $conf['pass_convert']($password))
  {
    log_user($row['id'], $remember_me);
    trigger_action('login_success', stripslashes($username));
    return true;
  }
  trigger_action('login_failure', stripslashes($username));
  return false;
}

C'est la correction que j'ai appliquée pour faire en sorte que le login soit ou non sensible à la casse à l'identification selon la valeur de $conf['insensitive_case_logon']. Procédure d'exemple:
1- Positionner $conf['insensitive_case_logon'] = false (valeur normalement par défaut)
2- Créer 2 comptes test/pwd1 et TEST/pwd2
3- Tester l'identification dans sur ces deux comptes. Cela doit fonctionner et c'est normal.
4- Positionner $conf['insensitive_case_logon'] = true
5- Re-tester l'identification sur ces deux comptes : Seul le compte TEST/pwd2 est accessible.

Alors que fait-on de test/pwd1 ?...

Vraiment pas simple...

Hors ligne

#13 2010-12-11 22:21:00

Whiler
Membre
Clichy
2004-12-24
189

Re: Insensible à la casse...

Eric a écrit:

Alors que fait-on de test/pwd1 ?...

Vraiment pas simple...

Avec un lowercase, lui devrait pouvoir s'authentifier....

les autres... ne passeront plus puisque leur mot de passe ne sera pas "pwd1"....


Le warning en haut de la page d'admin si des doublons existent est une excellente idée...

Je viens de faire le test : Seuls les webmasters sont autorisés à créer ou modifier les fichiers locaux.
avec LocalFiles Editor....

Hors ligne

#14 2010-12-11 22:30:55

Eric
Équipe Piwigo
VALENCE (FR)
2005-03-25
4579

Re: Insensible à la casse...

Whiler a écrit:

Eric a écrit:

Alors que fait-on de test/pwd1 ?...

Vraiment pas simple...

Avec un lowercase, lui devrait pouvoir s'authentifier....

les autres... ne passeront plus puisque leur mot de passe ne sera pas "pwd1"....

Bah non, justement, test/pwd1 ne peut pas s'identifier avec un lowercase. Bizarrement, c'est TEST/pwd2 et lui seul qui le peut... Et encore, c'est le cas d'école simple avec 2 comptes en faux doublon. Que dire lorsqu'il y en a plus (test/pwd1, Test/pwd2, TEST/pwd3,...) ?

Je cherche encore la solution la plus simple et rapide à mettre en oeuvre et qui conviendrait à tous les cas de figure en lésant un minimum d'utilisateur (aucun serait l'idéal).

Hors ligne

#15 2010-12-11 22:35:17

Whiler
Membre
Clichy
2004-12-24
189

Re: Insensible à la casse...

En fait... ils doivent tous pouvoir s'identifier (ok.. j'avoue, j'ai pas lu le code...)

Mais pourquoi je dis ça, parce que j'imagine :


Select * as nb from user where lower(name) = lower($name) and lower(password) = lower($pwd);


Si une ligne est renvoyée, c'est que c'est bon.. sinon, c'est que aucun test, TEST, ... n'a pour mot de passe celui qui est passé....


Bon, ok, si TEST et test ont le même mot de passe.. ils sont pas dans la m... :o))

$name & $pwd étant les variables passées par l'utilisateur
name & password étant les colonnes de la tables qui contient les credentials...

j'ai fait l'impasse sur les md5 et cie...

Hors ligne

  •  » Plugins
  •  » Insensible à la casse...

Pied de page des forums

Propulsé par FluxBB

github twitter facebook newsletter Faire un don Piwigo.org © 2002-2020 · Contact