Piwigo Bugtracker

Piwigo bug tracker has moved to Github

This bugtracker is kept to provide history on old issues.


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001835Piwigoauthenticationpublic2010.08.31 22:542011.08.06 15:29
ReporterLucMorizur 
Assigned Toflop25 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformAllOSAllOS Version
Product Version2.1.2 
Target VersionFixed in Version2.3.0beta3 
Summary0001835: Username case sensitivity
DescriptionSince branch 2.1 of Piwigo is now parameter $conf['insensitive_case_logon'] in config_default.inc.php. There is a problem due to the fact that when $conf['insensitive_case_logon'] is set to true, only the CREATION of usernames is case insensitive. When $conf['insensitive_case_logon'] is true :
  _ username creation of "Beatrice" -> OK.
  _ username creation of "beatrice" -> denied, this account already exists.
  _ identification attempt by visitor with username "bEatrice" -> DENIED, this account doesn't exist. This last case should be corrected.
See http://piwigo.org/forum/viewtopic.php?id=16119 [^] in english forum or http://fr.piwigo.org/forum/viewtopic.php?id=17946 [^] in the french forum.
Steps To ReproduceCreate a username and try different characters cases, to login with this new username
TagsNo tags attached.
browserany
Database engine and version
PHP version
Web serverApache 1.3.x
Attached Files

- Relationships

-  Notes
(0004623)
LucMorizur (reporter)
2011.01.05 09:41
edited on: 2011.01.05 09:58

To allow case insensitivity at logon, do the following:

In ./identification.php , add the following at line 57:

    if ($conf['insensitive_case_logon'] == true)
     $_POST['username'] = search_case_username($_POST['username']);

In ./include/functions_user.inc.php , add the following function :

/**
 * For test on username case sensitivity
 *
 * @param : $username typed in by user for identification
 *
 * @return : $username found in database
 *
 */
function search_case_username($username)
{
  global $conf;

  $username_lo = strtolower($username);

  $SCU_users = array();
  
  $q = pwg_query("
    SELECT ".$conf['user_fields']['username']." AS username
    FROM `".USERS_TABLE."`;
  ");
  while ($r = pwg_db_fetch_assoc($q))
   $SCU_users[$r['username']] = strtolower($r['username']);
   // $SCU_users is now an associative table where the key is the account as
   // registered in the DB, and the value is this same account, in lower case
   
  $users_found = array_keys($SCU_users, $username_lo);
  // $users_found is now a table of which the values are all the accounts
  // which can be written in lowercase the same way as $username
  if (count($users_found) != 1) // If ambiguous, don't allow lowercase writing
   return $username; // but normal writing will work
  else
   return $users_found[0];
}


This works well with all accounts which don't include accentuated characters (é, è...). With accentuated characters, it might be possible that strtolower() doesn't work well (to me, it works well with plain ISP "Free", but not with local installation with WampServer : strtolower() doesn't work the same way).

If $conf['insensitive_case_logon'] = false (default), Piwigo works as usually, meaning that account Test1 is different than TEST1, and if both are already existing on the gallery, you cannot create another account Test1, but you can create an account TEst1 ; and each of them will be able to logon only by spelling them properly.

If $conf['insensitive_case_logon'] = true, you will not be able to create account TEST2 if Test2 already exists on the gallery. But you will be able to logon account Test2 by spelling it TEST2. And if accounts Test1 and TEST1 was already existing on the gallery before setting $conf['insensitive_case_logon'] to true, then both of them will need to be spelled properly to be able to log on, and no account will be logged on when trying with TEst1.

(0004633)
rvelices (developer)
2011.01.10 22:28

it seems to me overly complicated
just put the database username column in non binary mode and it works ... (change utf8_bin to utf8_general_ci)
(0004634)
LucMorizur (reporter)
2011.01.10 22:40

rvelices:
> it seems to me overly complicated
> just put the database username column in non binary mode and it works ...
> (change utf8_bin to utf8_general_ci)

Do you think this change (username column from utf8_bin to utf8_general_ci) should be done within Piwigo core?

And actually I don't understand, all my tables are already on utf8_general_ci , this does not make user "Test" be the same as user "TEST"??
(0004635)
rvelices (developer)
2011.01.11 09:08

>> And actually I don't understand, all my tables are already on utf8_general_ci , this does not make user "Test" be the same as user "TEST"??
I'm talking about the username column, not the table itself
(0005058)
stim (reporter)
2011.04.26 21:26
edited on: 2011.04.26 21:36

I suggest you use the same method as in user registration, and only change what differs between the two options:
--- /include/functions_user.inc.php
+++ /include/functions_user.inc.php
@@ -1110,8 +1110,10 @@
 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).'\'
-;';
+ WHERE ';
+ $query.= ($conf['insensitive_case_logon']?'LOWER('.$conf['user_fields']['username'].') = \''.strtolower(pwg_db_real_escape_string($username)).'\''
+ :$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))
   {

(0005098)
flop25 (developer)
2011.05.12 16:14

-@sim
imagine you have a user Aaaaa and AAaaa registred before you put $conf['insensitive_case_logon'] = true;
The first user registered will be login whereas the second one will not be login !
So the problem is a bit more complexe

-so the code of LucMorizur is good : with the previous example no one can be registred using aaaaa as username, whereas a user called CCccc can be registred as ccccc because he is the only one

-change utf8_bin to utf8_general_ci : good but not compatible with the conf var and my previous example : Duplicate entry 'Aaaaa' for key 'users_ui1'

So LucMorizur's code adopted.
(0005099)
svn (reporter)
2011.05.12 16:26

[Subversion] r10860 by flop25 on trunk

-----[Subversion commit log]----------------------------------------------------
feature:1835
better managment if $conf['insensitive_case_logon'] is true, for identification
(0005101)
flop25 (developer)
2011.05.13 12:31

The solution make a query to retrieve every user from the database. While this solves the problem indeed, it's also a huge performance issue
(0005102)
stim (reporter)
2011.05.13 13:03
edited on: 2011.05.13 13:21

The following is a more optimized version of the search_case_username method.
(In the forum I forgot to use LOWER(..) in the query)

[code]
/**
 * For test on username case sensitivity
 *
 * @param : $username typed in by user for identification
 *
 * @return : $username found in database
 *
 */
function search_case_username($username)
{
  global $conf;

  $esc_username = pwg_db_real_escape_string(strtolower($username));

  $r = pwg_query("
    SELECT ".$conf['user_fields']['username']." AS username
    FROM `".USERS_TABLE."`
    WHERE LOWER(".$conf['user_fields']['username'].") = \"".$esc_username."\"
  ");

  if(pwg_db_num_rows($r) == 1)
  {
    $row = pwg_db_fetch_assoc($r);
    return $row['username'];
  }else{
    return $username;
  }
}
[/code]

Note: I updated my post, because I discovered some mistakes (sorry for my hurried reply)

(0005103)
flop25 (developer)
2011.05.13 15:39
edited on: 2011.05.13 15:39

we can't use LOWEr because of the compatibility between the type data base : Postgresql/MySQL/SQLite
Moreover it's a feature which is false by default, and concern gallery with a huge amount of users : it's too rare !

So the first initial commit will stay


- Issue History
Date Modified Username Field Change
2010.08.31 22:54 LucMorizur New Issue
2010.08.31 22:54 LucMorizur browser => any
2010.08.31 22:54 LucMorizur Web server => Apache 1.3.x
2011.01.05 09:41 LucMorizur Note Added: 0004623
2011.01.05 09:58 LucMorizur Note Edited: 0004623
2011.01.10 22:28 rvelices Note Added: 0004633
2011.01.10 22:40 LucMorizur Note Added: 0004634
2011.01.11 09:08 rvelices Note Added: 0004635
2011.04.26 21:26 stim Note Added: 0005058
2011.04.26 21:36 stim Note Edited: 0005058
2011.05.12 16:14 flop25 Note Added: 0005098
2011.05.12 16:26 svn Checkin
2011.05.12 16:26 svn Note Added: 0005099
2011.05.12 16:40 flop25 Status new => assigned
2011.05.12 16:40 flop25 Assigned To => flop25
2011.05.12 16:40 flop25 Status assigned => resolved
2011.05.12 16:40 flop25 Resolution open => fixed
2011.05.13 12:31 flop25 Note Added: 0005101
2011.05.13 12:31 flop25 Status resolved => feedback
2011.05.13 12:31 flop25 Resolution fixed => reopened
2011.05.13 13:03 stim Note Added: 0005102
2011.05.13 13:21 stim Note Edited: 0005102
2011.05.13 15:39 flop25 Note Added: 0005103
2011.05.13 15:39 flop25 Note Edited: 0005103
2011.08.06 15:29 flop25 Status feedback => closed
2011.08.06 15:29 flop25 Resolution reopened => fixed
2011.08.06 15:29 flop25 Fixed in Version => 2.3.0beta3


Copyright © 2000 - 2019 MantisBT Team
Contact
Powered by Mantis Bugtracker