Thanks to Platonides for his comment and also to Olivier (the author of the Realnames extension) who told me to forward the following patch to wikitech-l (which I just subscribed to) for advices, comments and critics.
I was just wondering if this small patch in User.php (function idFromName) was enough in most cases:
$dbr = wfGetDB( DB_SLAVE ); $s = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_name' => $nt->getText() ), __METHOD__ );
if ( $s === false ) { //Start Patch $result = null; $stwo = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_email' => $nt->getText() ), __METHOD__ ); if ( $stwo === false ) { $result = null; }else { $result = $stwo->user_id; } //End patch } else { $result = $s->user_id; }
Then, just try to enter your e-mail on a standard wiki in place of your username and you will be authenticated to the first ID (and user_name) having your e-mail.
The importance of e-mails as a simple way to authenticate on modern sites can't be ignored.
If you want to enter your standard username for authentication you can do it too.
But if your username is not a Roman but an Arabic, Thai, Japanese etc. username or even a French username with accents and if you decided to have authorship recognized in your own language and not only in a English transliterated way, you can also do it with as standard mediawiki installation. But if you are working with somebody who has an English keyboard only, the copy-paste of your Unicode username may be tedious and you would prefer to enter your e-mail address.
The modified Login form could be:
Username (or e-mail address): |___________________| Password: |___________________|
If someone could test this patch above and report the security issues as well as performances, it could be great for us.
We are managing Demopaedia.org and are willing to open the site to professional demographers (being already subscribed to a national or international union for the scientific study of population). We will not use various LDAP authentication processes but use local standard mediawiki databases. The usual way to be authenticated is the e-mail and password, and we want to keep this option. If you look (for example) at the work of Mikael, his work is authored in Cyrillic: Михаил Денисенко on http://ru-ii.demopaedia.org/w/index.php?title=90&action=history, other Russian authors use the transliteration. It is a question of taste.
If Mikael is traveling and doesn't have a Cyrillic keyboard, he would be pleased to enter his email to authenticate. The password to be entered is the password linked with his username.
For people having multiple usernames (pseudos) with the same e-mail but different passwords for each, a better patch could be to test the password entered and to link with the unique username. But I am not an expert in mediawiki and php and don't know how to get the password within the function idFromName.
I understand that e-mails should not be revealed and the above patch satisfies this condition.
Comments, advices, critics, code are welcome.
Nicolas
Le 15 févr. 2012 à 23:57, Platonides a écrit :
On 13/02/12 19:56, Nicolas Brouard INED wrote:
Thanks John for your comment. It would mean that people logging with an email will have a default account (lowest ID with the same email or whatever rule).
For authorship Wikimedia doesn't encourage multiple account names (multiple (>3?) pseudos are blamed). And usually, for a corporate wiki you don't have multiple accounts. If you decide to change your name for any reason (divorce for example) you are supposed to have a (new) unique name. You usually can also have email aliases.
And if you want to log on a specific account name, you can copy and paste your account name (if your keyboard doesn't allow you to enter your real, not transliterated, name).
Thus, I am not sure that it is strong objection for corporate wikis at least.
PS: I am trying to understand how to have a working MyAuthPlugin.php and to get the email in authenticate but it requires time and I haven't found so many examples on the Web.
Any hint or comment is welcome.
Nicolas
I don't think you can do that with just an auth plugin. You would need to modify the SpecialUserLogin code to look for that email.
PS: What's the big issue with copy&paste or transliteration? Doesn't your users have a keyboard layout able to type *their own name*? I understand the issue when a third party needs to enter them, but eg. Russian people usually have/can switch to a cyrillic keyboard layout.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Nicolas Brouard INED brouard@ined.fr
Nicolas Brouard INED schrieb:
Then, just try to enter your e-mail on a standard wiki in place of your username and you will be authenticated to the first ID (and user_name) having your e-mail.
Great Idea!
If someone could test this patch above and report the security issues as well as performances, it could be great for us.
No idea about PHP and performance, but a possible security hole: Are there any system messages that output the username when failing to login? If these messages would use the username from the database query (because of normalizing or something?) and not from $_POST, you could find out users' email adresses.
Bergi
Le 16 févr. 2012 à 17:45, Bergi a écrit :
Nicolas Brouard INED schrieb:
Then, just try to enter your e-mail on a standard wiki in place of your username and you will be authenticated to the first ID (and user_name) having your e-mail.
Great Idea!
Thank you. Now we have to convince developers transforming this idea into reality...
If someone could test this patch above and report the security issues as well as performances, it could be great for us.
No idea about PHP and performance, but a possible security hole: Are there any system messages that output the username when failing to login?
We tested this patch already on some wikis.
The patch is very short as you can see. If the e-mail entered doesn't belong to the user_name list, the e-mail is test amongst the user_email list. If the e-mail doesn't belong to the user_email list (no row and thus no user_id with this e-mail) the null return is similar to a null return because of a unknown user_name and thus a message is sent with an "Unknown user" with the e-mail (and not the user_name).
It the e-mail belongs to the list of e-mails,
mysql> SELECT user_id, user_name, user_email FROM wikidb WHERE user_email='jfox@foo.fr; +---------+-----------------+-----------------+ | user_id | user_name | user_email | +---------+-----------------+-----------------+ | 2 | John Fox | jfox@foo.fr | | 3 | JFBot | jfox@foo.fr | | 443 | John FOX | jfox@foo.fr | +---------+-----------------+-----------------+
an array of corresponding user_id is sent and the first user_id (here 2) is chosen by default if you are not asking for an array in selectRow.
If you entered the password of "John Fox", you will be logged as is you entered "John Fox" instead of "jfox@foo.fr". If you entered a wrong password for John Fox, for example the password of John FOX, Wikipedia will tell you that the password for "jfox@foo.fr" is wrong.
If you ask for new password to be sent, you will receive an e-mail at the name of John Fox, not John FOX nor JFBot, but it is an e-mail at your e-mail box and I don't see any trouble.
If these messages would use the username from the database query (because of normalizing or something?) and not from $_POST, you could find out users' email adresses.
I hope that my previous explanations are also answering your above issue which I do not completely understand.
Regards,
Nicolas
Bergi
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Nicolas Brouard INED brouard@ined.fr
2012/2/16 Nicolas Brouard INED brouard@ined.fr
For people having multiple usernames (pseudos) with the same e-mail but different passwords for each, a better patch could be to test the password entered and to link with the unique username. But I am not an expert in mediawiki and php and don't know how to get the password within the function idFromName.
This is an important point. For example, I have 3 bot accounts that all have my e-mail for practical reasons. I wouldn't be happy with logging in as one of them. :-)
Le 16 févr. 2012 à 20:51, Bináris a écrit :
2012/2/16 Nicolas Brouard INED brouard@ined.fr
For people having multiple usernames (pseudos) with the same e-mail but different passwords for each, a better patch could be to test the password entered and to link with the unique username. But I am not an expert in mediawiki and php and don't know how to get the password within the function idFromName.
This is an important point. For example, I have 3 bot accounts that all have my e-mail for practical reasons. I wouldn't be happy with logging in as one of them. :-)
For bot accounts, you can and should still log using a specific bot username.
There is no ambiguity in the proposed patch, it checks if the username (user_name field) exists and if yes it checks the corresponding password. It is only when the username doesn't exist that it checks if a user_email exists. If a user_email exists it could be an array of user_id and instead of returning the first element of this array (and hoping that the password entered will match this ID) we could propose a better algorithm.
That is the reason why I say that this simple patch works in most cases (90 %? A simulation could be done with the Wikipedia dbs): if you are not authenticated using an e-mail and password to the username you wanted, you need to enter the standard way i.e with username and same password.
Regards,
-- Nicolas
On 16/02/12 09:51, Nicolas Brouard INED wrote:
Thanks to Platonides for his comment and also to Olivier (the author of the Realnames extension) who told me to forward the following patch to wikitech-l (which I just subscribed to) for advices, comments and critics.
I was just wondering if this small patch in User.php (function idFromName) was enough in most cases:
$dbr = wfGetDB( DB_SLAVE ); $s = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_name' => $nt->getText() ), __METHOD__ ); if ( $s === false ) { //Start Patch $result = null; $stwo = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_email' => $nt->getText() ), __METHOD__ ); if ( $stwo === false ) { $result = null; }else { $result = $stwo->user_id; } //End patch } else { $result = $s->user_id; }
This is only patching User::idFromName(), which won't be enough. You could well be storing the email instead of the username in the page history.
As I said, you should fix it in SpecialUserlogin.php.
Then, just try to enter your e-mail on a standard wiki in place of your username and you will be authenticated to the first ID (and user_name) having your e-mail.
The importance of e-mails as a simple way to authenticate on modern sites can't be ignored.
It can also expose the fact that someone is registered there with that email address. In the patch provided, it would also happily show under some circunstances the username associated to an email (not a problem for the internal wiki of a company, where everybody know each other's mail, an issue for public wikis out there).
If you want to enter your standard username for authentication you can do it too.
But if your username is not a Roman but an Arabic, Thai, Japanese etc. username or even a French username with accents and if you decided to have authorship recognized in your own language and not only in a English transliterated way, you can also do it with as standard mediawiki installation. But if you are working with somebody who has an English keyboard only, the copy-paste of your Unicode username may be tedious and you would prefer to enter your e-mail address.
The modified Login form could be:
Username (or e-mail address): |___________________| Password: |___________________|
Changing the text displayed there is trivial (edit MediaWiki:yourname).
If someone could test this patch above and report the security issues as well as performances, it could be great for us. We are managing Demopaedia.org and are willing to open the site to professional demographers (being already subscribed to a national or international union for the scientific study of population). We will not use various LDAP authentication processes but use local standard mediawiki databases. The usual way to be authenticated is the e-mail and password, and we want to keep this option. If you look (for example) at the work of Mikael, his work is authored in Cyrillic: Михаил Денисенко on http://ru-ii.demopaedia.org/w/index.php?title=90&action=history, other Russian authors use the transliteration. It is a question of taste.
If Mikael is traveling and doesn't have a Cyrillic keyboard, he would be pleased to enter his email to authenticate. The password to be entered is the password linked with his username. For people having multiple usernames (pseudos) with the same e-mail but different passwords for each, a better patch could be to test the password entered and to link with the unique username. But I am not an expert in mediawiki and php and don't know how to get the password within the function idFromName.
I understand that e-mails should not be revealed and the above patch satisfies this condition.
Comments, advices, critics, code are welcome.
Nicolas
An alternative solution to the original problem could be an extension that displays possible characters from several alphabets and helps to generate the username with mouse and put it back to the login name/password field. It would appear as a link or button next to the login name field. No security risks. Is that a crazy idea or difficult to solve?
Bináris schrieb:
An alternative solution to the original problem could be an extension that displays possible characters from several alphabets and helps to generate the username with mouse and put it back to the login name/password field.
I don't think that would be a good idea. * It sounds as it would need JavaScript (or would be difficult to implement) * clicking is much slower than typing * "possible characters from several alphabets"? You know, we support the full set of Unicode. Displaying all unicode blocks would need the user to remember from which block his characters are * One version of the problem is that you try to login from a system that doesn't support your characters with any font. "displaying characters" is the heavy task. If we don't want to show pictures, the user needs to remember the individual character codes. (or is there a usable all-unicode web font?)
Therefore, it is a great idea to login with your email address, which usually consists of latin characters. I have that problem myself, beeing User:✓ (a great challenge for toolserver tools ;-). Usually I have: * My browsers autologin function which fills in the username at known wikis * My browsers "notice" function which allows me to insert various texts with the contextmenu * Once logged in, I have a extraeditbutton above the edit form * or can c&p the sign from the #p-personal portlet (user page, user disk, prefs...) But when I try to login no at my home system, I'm challenged how to insert the 0x2713 char code with the keyboard. At windows Alt + num pad usually works, but... So I often end up googling for "unicode checkmark", and c&p the character from wikipedias "List of Unicode characters" :-(
Regards, Bergi
Le 17 févr. 2012 à 14:28, Bergi a écrit :
Bináris schrieb:
An alternative solution to the original problem could be an extension that displays possible characters from several alphabets and helps to generate the username with mouse and put it back to the login name/password field.
I don't think that would be a good idea.
- It sounds as it would need JavaScript (or would be difficult to implement)
- clicking is much slower than typing
- "possible characters from several alphabets"? You know, we support the full set of Unicode. Displaying all unicode blocks would need the user to remember from which block his characters are
- One version of the problem is that you try to login from a system that doesn't support your characters with any font. "displaying characters" is the heavy task. If we don't want to show pictures, the user needs to remember the individual character codes.
(or is there a usable all-unicode web font?)
Therefore, it is a great idea to login with your email address, which usually consists of latin characters. I have that problem myself, beeing User:✓ (a great challenge for toolserver tools ;-). Usually I have:
- My browsers autologin function which fills in the username at known wikis
- My browsers "notice" function which allows me to insert various texts with the contextmenu
- Once logged in, I have a extraeditbutton above the edit form
- or can c&p the sign from the #p-personal portlet (user page, user disk, prefs...)
But when I try to login no at my home system, I'm challenged how to insert the 0x2713 char code with the keyboard. At windows Alt + num pad usually works, but... So I often end up googling for "unicode checkmark", and c&p the character from wikipedias "List of Unicode characters" :-(
Thank you for your support. I just submitted a complete patch entitled "Can't authenticate using my mother language username (UNICODE) when I only have (a public) access to Wikipedia with an ASCII (english) keyboard" in about 20 languages on https://bugzilla.wikimedia.org/show_bug.cgi?id=34590
People supporting this idea, please for it.
Here is the text: This is a real issue for people who have registered with a username having UNICODE and non ASCII (7 bits) characters and who want to login to Wikipedia when they are abroad with a simple English keyboard and want to edit some pages (usually English pages).
The fact that Wikipedia and Mediawikis do not offer the possibility to authenticate with an e-mail is now considered, at least for me, as a bug.
I recently discussed this fact on Wikitech-l ("Great idea" http://lists.wikimedia.org/pipermail/wikitech-l/2012-February/058183.html) and some tests have been made trying to answer legitimate questions (see http://lists.wikimedia.org/pipermail/wikitech-l/2012-February/058253.html) to a simple patch that I proposed.
This small patch in User.php (function idFromName) is enough in most cases:
$dbr = wfGetDB( DB_SLAVE ); $s = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_name' => $nt->getText() ), __METHOD__ );
if ( $s === false ) { //Start Patch $result = null; $stwo = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_email' => $nt->getText() ), __METHOD__ ); if ( $stwo === false ) { $result = null; }else { $result = $stwo->user_id; } //End Patch } else { $result = $s->user_id; } The modified Login form is:
Username (or e-mail): |___________________| Password: |___________________|
The full attached patch is rendering this new form in about 20 languages (that is what we need in our wikis). The patch is simply adding two new msg: - 'yournameoremail' instead of 'yourname' in Userlogin.php and - 'passwordreset-usernameoremail' instead of 'passwordreset-username' in SpecialPasswordReset.php .
In order to explain this new experimental feature, we added a Hook in LocalSettings.php :
function efLoginFormMessage( &$template ) { $template->set( 'header', "NEW (experimental): if you are a registered user with an authenticated e-mail, you can also log in with your e-mail address in place of your username. Your e-mail is used only during the authentication phase; if successful you will be logged with your standard username. <br />Please notice that for people owning different accounts with the same e-mail, you will be logged in with your first registered username (lowest ID). If the password entered doesn't match the password of your lowest registered ID, you can't authenticate this way and should enter your desired username."); return true; } $wgHooks['UserLoginForm'][]='efLoginFormMessage';
I hope that this patch will be visited and accept. It is changing our live here. People having been registered with accented characters or in Cyrillic can use their e-mail to get their temporary password by e-mail while still being able to sign authorship in Cyrillic or with accented characters avoiding the English transliteration. Others still prefer the English transliteration, it is a question of taste.
Without this patch, people are using the English transliteration for the commodity of authentication.
Regards, Nicolas
Regards, Bergi
Great, thanks!
What will this do if I have multiple user names on the same e-mail?
What will this do if I have multiple user names on the same e-mail AND the same password? (For me it would be a good solution to choose the user with the smallest id.)
On Wed, Feb 22, 2012 at 10:35 PM, Bináris wikiposta@gmail.com wrote:
Great, thanks!
What will this do if I have multiple user names on the same e-mail?
What will this do if I have multiple user names on the same e-mail AND the same password? (For me it would be a good solution to choose the user with the smallest id.)
It should reject it then request the username be entered, Not everyone would like it (if they were in that situation) to randomly log into their oldest account.
On Wed, Feb 22, 2012 at 4:24 AM, Nicolas Brouard brouard@ined.fr wrote:
Thank you for your support. I just submitted a complete patch entitled "Can't authenticate using my mother language username (UNICODE) when I only have (a public) access to Wikipedia with an ASCII (english) keyboard" in about 20 languages on https://bugzilla.wikimedia.org/show_bug.cgi?id=34590
People supporting this idea, please for it.
Cool!
See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=28085, a bug I submitted ages ago based on feedback I've gotten talking to users who only occasionally edited. The idea is that that remembering a username can be a barrier to casual editing (a few tries to remember a username that you don't use much and you might just give up) -- and being able to log in with an email address might help make things smoother.
-- phoebe
Le 23 févr. 2012 à 02:01, phoebe ayers a écrit :
On Wed, Feb 22, 2012 at 4:24 AM, Nicolas Brouard brouard@ined.fr wrote:
Thank you for your support. I just submitted a complete patch entitled "Can't authenticate using my mother language username (UNICODE) when I only have (a public) access to Wikipedia with an ASCII (english) keyboard" in about 20 languages on https://bugzilla.wikimedia.org/show_bug.cgi?id=34590
People supporting this idea, please for it.
Cool!
See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=28085, a bug I submitted ages ago based on feedback I've gotten talking to users who only occasionally edited. The idea is that that remembering a username can be a barrier to casual editing (a few tries to remember a username that you don't use much and you might just give up) -- and being able to log in with an email address might help make things smoother
Thank you for pointing me on your older bug that I didn't find on Bugzilla before I submitted this current bug. The aim was different but the solution to be found is the same. I haven't seen a proposed patch neither by yourself nor anyone else, am I wrong?
Concerning the patch submitted, and in order to have an idea of the pertinence of it for other MediaWikis sites than mine and Wikipedia too, I am asking people having access to the standard user database of their wikis to process this next mysql command.
The question is how many people are sharing a unique e-mail with several usernames? mysql -u wikiadmin -p wikidb mysql> select email_freq, COUNT(email_freq) FROM (select user_email, COUNT(user_email) as email_freq FROM prefix_user WHERE user_email <> "NULL" GROUP BY user_email ) AS DISTRIB GROUP BY email_freq;
Here is the result on mine: +------------+-------------------+ | email_freq | COUNT(email_freq) | +------------+-------------------+ | 1 | 3047 | | 2 | 22 | | 3 | 1 | +------------+-------------------+
On the above example, 22 users have 2 usernames having the same e-mail. 1 have 3, and all the others have an e-mail link to a unique username. I suppressed the number of people having no e-mail authenticated (NULL).
The benefit of this patch won't be as good on Wikipedia user table, but I would be happy if you know who I can ask in order to get the results. I was guessing 90% but I am probably pessimistic... -- Nicolas
-- phoebe
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 16 févr. 2012 à 22:26, Platonides a écrit :
On 16/02/12 09:51, Nicolas Brouard INED wrote:
Thanks to Platonides for his comment and also to Olivier (the author of the Realnames extension) who told me to forward the following patch to wikitech-l (which I just subscribed to) for advices, comments and critics.
I was just wondering if this small patch in User.php (function idFromName) was enough in most cases:
$dbr = wfGetDB( DB_SLAVE ); $s = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_name' => $nt->getText() ), __METHOD__ ); if ( $s === false ) { //Start Patch $result = null; $stwo = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_email' => $nt->getText() ), __METHOD__ ); if ( $stwo === false ) { $result = null; }else { $result = $stwo->user_id; } //End patch } else { $result = $s->user_id; }This is only patching User::idFromName(), which won't be enough.
Sorry, could you detail why it won't be enough!
You could well be storing the email instead of the username in the page history.
I was probably not clear enough: I don't want the email in the page history. Also the Realnames extension (quoted above) is trying to do what you seem suggesting but it is a complex extension which did not work on 1.18 for example.
The proposed patch is also a solution which manages the transition for Wikipedians. Having an authentication with e-mail only is brutal and won't be understood. I like the possibility of having both option with a priority to username for performance also.
But allowing new authors from Arabic or Asian (or Russian or ...) countries (with non Roman characters) to sign new articles in their own language with their own standard, not transliterated, signature will be appreciated if they also have an easy way to authenticate on an English keyboard (pad, smartphone etc.).
As I said, you should fix it in SpecialUserlogin.php.
What should I fix? Is there something wrong in the proposed patch?
Then, just try to enter your e-mail on a standard wiki in place of your username and you will be authenticated to the first ID (and user_name) having your e-mail.
The importance of e-mails as a simple way to authenticate on modern sites can't be ignored.
It can also expose the fact that someone is registered there with that email address.
I don't understand what you mean and if someone has already entered an email for a username what is the problem?
In the patch provided, it would also happily show under some circunstances the username associated to an email (not a problem for the internal wiki of a company, where everybody know each other's mail, an issue for public wikis out there).
That is the reason why I was asking this mailing list. But, as I said in a previous and detailed answer to Bergi, the patch is very short (a single "if") and thus consequences are not tremendous.
We made some tests on various wikis, and we haven't found yet any circumstance where the username associated to an email is displayed: - it can't happen when the authentication works; - the only situation that I have found is when you are asking for a new password: then the username associated with the email entered (in place of the username) is displayed in the received email, but it is not a security issue because you are the only person to read your email.
If you want to enter your standard username for authentication you can do it too.
But if your username is not a Roman but an Arabic, Thai, Japanese etc. username or even a French username with accents and if you decided to have authorship recognized in your own language and not only in a English transliterated way, you can also do it with as standard mediawiki installation. But if you are working with somebody who has an English keyboard only, the copy-paste of your Unicode username may be tedious and you would prefer to enter your e-mail address.
The modified Login form could be:
Username (or e-mail address): |___________________| Password: |___________________|
Changing the text displayed there is trivial (edit MediaWiki:yourname).
It seems that MediaWiki:Yourname is deprecated. The "(or e-mail address)" sentence must be translated too in all languages (more than 15 for Demopaedia). But I think that it is no a problem neither for us nor for Wikipedia.
Thanks for your comments,
-Nicolas
wikitech-l@lists.wikimedia.org