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...

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)

;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 !

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 ?

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 ?

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:

/**
 * 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...

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).