But can I ask, why restrict those keyboard characters in usernames?
I will let Drak address the answer to that question.
Also, I have a question about usernames case.
I've always thought (and told members) that usernames were not case sensitive, that UserName was the same as username. In Zikula 1.2+ the user module has a setting "New username in lowercase" that is explained as "When enabled, if a new user chooses 'MyUserName' as his/her username, it will be stored as 'myusername' in the Zikula database."
I don't understand the point of this if usernames are not case sensitive?
This might get a little on the technical side, and a bit on the long side. In order to make user names not case sensitive, they have to be compared in a non-case-sensitive manner when they are used. For example, when logging in as "Robert" or "rObert" we have to ensure that these user names are compared to "robert" (or whatever) without regard to case.
One might think, "well, then just convert both to lower (or upper) case before you compare them," and that would be thinking in the right direction, but there is a problem that we must first overcome. We need to find the user name in the database. Let's say that my fat fingers register on your system as "rObert", but that I try to log in as "Robert" since I was told that user names are not case sensitive. Database servers are dumb. They have no way to know that "rObert" should match "Robert" without being told somehow that they are the same value. When I try to log on as "Robert", assuming we have implemented a case-sensitive system, I will get rejected as an unknown users.
So, how do we make it ignore case? MySQL has a LOWER() function that we can use in queries to convert a retrieved value to lower case when we are doing the WHERE comparison. Using that plus a
PHP function to convert the entered value to lower case, we can force MySQL to consider "rObert" and "Robert" as the same value. Ok, so problem solved, right?
Not quite. That was fine back when we supported MySQL to the near exclusion of all other database platforms. While MySQL is the prevalent database system used out there with web servers, it is not the only one. With successive versions of Zikula, we have been trying to expand the number of potential configurations on which the system will run. Because of this, we cannot rely on the behavior of any one database platform. What if another database server we support doesn't have the LOWER() function? Worse, what if it does have it, but acts differently? What about non-ASCII characters? How are they handled by the LOWER() function? Are they handled the same way by every database server? Sadly, the answers to those questions tell us that we cannot assume that the
SQL LOWER() function is available, and even if it is, that it will behave the way we expect it to.
In order to reliably make user names case-insensitive, we have to then back up a bit from the database layer to something that all implementations have in common. That would be
PHP. We can count on the
PHP functions to behave the same across platforms because, by definition, they have to. Unfortunately, we cannot use
PHP functions in
SQL queries. That means we have to use them
before the original data is stored, and then again
before we put together a query to search through the original data. Why before? Because if we did not, then every time we had to query for a user name we'd have to read the entire user database into an array and convert all of the user names to lower case before we could do a query, and we would have to search through the array instead of having the database server do the searching for us. Not very efficient.
Since we have to use these functions prior to storing the data, the most efficient way of handling these queries is storing the user name in all lower case. (We could have picked upper case, but lower case is easier on the eyes--and is somewhat standard across the industry.) Once we do that, we don't have to worry about case when we query. We build the query with the entered user name converted to lower case, and then the database server does not have to do any conversions on its own. Importantly, we don't have to worry about how different database servers handle the conversion of international characters to lower case, or worry about whether it supports such conversions at all.
The configuration option you refer to is a transitional option. If that is set, then all user names are stored as lower case, and if your implementation is on a non-MySQL server, then you have to worry less about potential assumptions of MySQL-specific things in the system causing you problems.
In 1.3.0, this will not be an option. All user names are all lower case all the time. The conversion is done during the upgrade.
--
- Robert
