Last modified: 2014-11-17 09:45:17 UTC
Created attachment 10067 [details] Patch for allowing user_name OR user_email authentication on Wikipedia Can't authenticate using my mother language username (UNICODE) when I only have (a public) access to Wikipedia with an ASCII (english) keyboard 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,
This bug addresses several issues. One seems to be that you need Narayam extension to be able to use the needed input method. The second is the login by email, which is proposed as a different issue and solution. By the way, can't email now be in non-ASCII characters too, as the domain name rules changed recently?
(In reply to comment #1) > By the way, can't email now be in non-ASCII characters too, as the > domain name rules changed recently? Was just looking at this the other day for Bug 34491 https://en.wikipedia.org/wiki/Internationalized_domain_name
Nicolas, thanks for your effort and for your interest in improving Wikimedia technology. I've just added the "patch" and "need-review" keywords, per https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Submit_your_changes . Thanks!
(In reply to comment #2) > (In reply to comment #1) > > By the way, can't email now be in non-ASCII characters too, as the > > domain name rules changed recently? > > Was just looking at this the other day for Bug 34491 > > https://en.wikipedia.org/wiki/Internationalized_domain_name Since the development of e-mails and VT200 we could have, locally, accented characters (8 bits characters) in e-mail aliases (in the local part of an e-mail before the @). I remember that it was even more important for user names ("not loosing our precious accented characters"), than the domain name which was usually written (in the real world) in uppercase and most of time without accents. But since that mid 80's, e-mails with accented characters did not work internationally and has been abandoned. Today, I know that the IDN project is closer to reality. But it is a transcription in ASCII of a UNICODE strings and it should not be a problem. And for example mailtest@xn--mgbh0fb.xn--kgbechtv is the Punycode (To-Ascii) transformation of the Arabic domain: mailtest@مثال.إختبار (see http://idn.icann.org/E-mail_test) With the attached patch installed, I discovered that when subscribing a new user having "Mail test" for username and mailtest@xn--fsqu00a.xn--g6w251d for its IDN To-ASCII formatted e-mail address, everythings works. But entering a new user with its IDN Unicode e-mail address mailtest@例子.測試 is not accepted yet by Mediawiki (it complains that the e-mail address is invalid). Thus, IDN doesn't seem to be an issue neither yet nor in the future. When the local part of an e-mail would be allowed to contain Unicode characters too, the To-Ascii form will always work. In this future world, people might still prefer enter an e-mail, like entêté@prosélytisme.fr instead of a pseudo like "Entêtement ou opiniâtreté" in order to authenticate on Wikipedia. The patch is a plus and would benefit to many many people.
I'm not really sure that patching User::newFromId is the right way to handle this. This fix should be in Special:UserLogin and should handle an email being attached to several accounts more gracefully.
(In reply to comment #4) > But entering a new user with its IDN Unicode e-mail address mailtest@例子.測試 is > not accepted yet by Mediawiki (it complains that the e-mail address is > invalid). But when it will, again entering such characters will be a problem. > Thus, IDN doesn't seem to be an issue neither yet nor in the future. When the > local part of an e-mail would be allowed to contain Unicode characters too, the > To-Ascii form will always work. Are you saying that having to enter the email address as mailtest@xn--mgbh0fb.xn--kgbechtv is something working? It seems worse than having to copy and paste (or whatever) a username with special characters (which at least you know). Anyway, I don't have an opinion; I only tried to say that using email instead of username doesn't seem a proper solution to the problem; the solution is having working input methods.
(In reply to comment #1) > This bug addresses several issues. > One seems to be that you need Narayam extension to be able to use the needed > input method. > The second is the login by email, which is proposed as a different issue and > solution. By the way, can't email now be in non-ASCII characters too, as the > domain name rules changed recently? Yes, Narayam is an important extension. It is not installed on all Wikimedia sites. And you should already have a site in Hindi for example in order to access to the Hindi (and Hindi only input method). You can't log on the English Wikipedia but have to find a Hindi page and log from there. Narayam looks interesting for entering longer text. For authentication only, it seems a high load. See the response of Bergi even for European languages at http://lists.wikimedia.org/pipermail/wikitech-l/2012-February/058221.html
(In reply to comment #5) > I'm not really sure that patching User::newFromId is the right way to handle > this. This fix should be in Special:UserLogin and should handle an email being > attached to several accounts more gracefully. Could you explain in more details what do you have in mind? An email sent for what purpose?
In order to know how frequent multiple usernames have the same e-mail, I would like to get the result of the mysql command on some of your wikis including Wikipedia: 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). It won't be the same benefit of this patch to Wikipedia users, 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...
(In reply to comment #3) > Nicolas, thanks for your effort and for your interest in improving Wikimedia > technology. > > I've just added the "patch" and "need-review" keywords, per > https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Submit_your_changes > . Thanks! Thank you Sumana for reading this bug. The attached patch is a unified diff but was against branch REL1_18 and not against the trunk. I did an svn diff against the current trunk this morning and am posting a more suitable patch.
Created attachment 10123 [details] Patch2 for allowing user_name OR user_email authentication on Wikipedia Patch2 for allowing user_name OR user_email authentication on Wikipedia. This patch is against the svn current trunk and not against the REL1_18 as for the previous patch. I hope that it will help.
I'm not really a fan of this idea. It just seems wrong (in a gut feeling kind of way; Don't really have a logical reason) to use email as a log in credential. I would much prefer we provided an on-screen keyboard type thing, or some other solution, to allow people to actually type their username, rather then letting people log in with email. ---- In regards to the patch: *For future reference, don't worry about any of the translation files except for english (and qqq). Non-english translations are handled elsewhere by a different group of people (translatewiki). *The patch doesn't actually work because it tries to apply title normalization to the user's input, but emails aren't usually title normalized (aka emails often start lowercase, but the code in patch capitalizes first letter. ditto for underscore). *Type an email in special:contributions. You can now given an email, associate a user with that email. That's a bad thing (emails are supposed to be secret). Some far fetched things to double check: *What if someone has an @ in their name. (Illegal since a very long time, but potentially some legacy users, not sure about that. Probably something not to worry about) *Will this interfere with using @ to denote what wiki the user is at in some cross wiki rights things (I doubt it, but i don't really know how those cross wiki rights things work, so should be double checked) *What about someone trying every possible email in the login form to see which ones they get "No such users" and which ones they get "password wrong" and then uses that to make a list of email addresses for spamming purposes (yes there's the throttle thing, but still kind of scary possibility) ----- Marking patch as reviewed do to the above mentioned issues.
(In reply to comment #12) > I'm not really a fan of this idea. It just seems wrong (in a gut feeling kind > of way; Don't really have a logical reason) to use email as a log in > credential. > Thanks for reviewing the patch. > I would much prefer we provided an on-screen keyboard type thing, or some other > solution, to allow people to actually type their username, rather then letting > people log in with email. > This is an opinion only (already discussed by some people) and it is more an opinion of a developer that from a user (I think). > ---- > In regards to the patch: > *For future reference, don't worry about any of the translation files except > for english (and qqq). Non-english translations are handled elsewhere by a > different group of people (translatewiki). As I wrote, I need these 20 languages and the translation is currently operational on our wikis. > *The patch doesn't actually work because it tries to apply title normalization > to the user's input, but emails aren't usually title normalized (aka emails > often start lowercase, but the code in patch capitalizes first letter. ditto > for underscore). Every one knows that the title normalization of Wikipedia is already useless in many languages. Uppercase is really from a western culture. Thus when you say "doesn't actually work", you could have written "is not appropriate" or something more neutral. I just kept the same transformation (title normalization) in order to show that the patch is very simple and that you should not see any complication by suppressing the normalization. But an email normalization could look better. On our system, and using mysql, it works. I haven't tested with postgresql. > *Type an email in special:contributions. You can now given an email, associate > a user with that email. That's a bad thing (emails are supposed to be secret). This point is very very important. But from what you said, I am sure that if you reviewed the patch, you did not test it! As said in previous discussions, if you enter an email instead of a username in Special:UserContribution, you get nothing: ------------------------ User contributions For Brouard@ined.fr (talk | block log | uploads | logs) Search for contributions Show contributions of new accounts only IP address or username: Namespace: Deleted only Only show edits that are latest revisions From year (and earlier): From month (and earlier): No changes were found matching these criteria. ------------------- but if you enter the name "Nicolas Brouard" you get: ------------------- (Latest | Earliest) View (newer 50 | older 50) (20 | 50 | 100 | 250 | 500) 12:29, 1 November 2011 (diff | hist) Talk:62 (Zeugungsunfähigkeit) (top) 09:06, 10 October 2011 (diff | hist) N Category:Term of the second edition of the multilingual demographic Dictionary (redirect) (Some explanations) (top) 23:25, 24 September 2010 (diff | hist) Template:NewTextTerm (top) 18:55, 24 September 2010 (diff | hist) m Category:To be checked (top) 18:30, 24 September 2010 (diff | hist) Category:To be checked (Which pages should I check?) 18:26, 24 September 2010 (diff | hist) m Category:To be checked (→Summary of parameters of NewTextTerm or TextTerm) -------------- > Marking patch as reviewed do to the above mentioned issues. Needs probably tests and not only reviews. I can provide logins if somebody want to test the patch. Regards
(In reply to comment #13) > (In reply to comment #12) > > I'm not really a fan of this idea. It just seems wrong (in a gut feeling kind > > of way; Don't really have a logical reason) to use email as a log in > > credential. > > > > > Thanks for reviewing the patch. > > > I would much prefer we provided an on-screen keyboard type thing, or some other > > solution, to allow people to actually type their username, rather then letting > > people log in with email. > > > > This is an opinion only (already discussed by some people) and it is more an > opinion of a developer that from a user (I think). > > > > > ---- > > > In regards to the patch: > > *For future reference, don't worry about any of the translation files except > > for english (and qqq). Non-english translations are handled elsewhere by a > > different group of people (translatewiki). > > As I wrote, I need these 20 languages and the translation is currently > operational on our wikis. My apologies, I must have missed that. > > > *The patch doesn't actually work because it tries to apply title normalization > > to the user's input, but emails aren't usually title normalized (aka emails > > often start lowercase, but the code in patch capitalizes first letter. ditto > > for underscore). > > Every one knows that the title normalization of Wikipedia is already useless in > many languages. Uppercase is really from a western culture. > > Thus when you say "doesn't actually work", you could have written "is not > appropriate" or something more neutral. I just kept the same transformation > (title normalization) in order to show that the patch is very simple and that > you should not see any complication by suppressing the normalization. But an > email normalization could look better. On our system, and using mysql, it > works. I haven't tested with postgresql. By doesn't actually work I do mean doesn't actually work. My email address on my test wiki install is bawolff@localhost. Typing "bawolff@localhost" in to the log in box does not log me into the account, as this patch looks for user's with the address "Bawolff@localhost" (I also tried an account with an email address containing underscores which failed for similar reasons. These were not bad examples meant to make the patch fail. These were the pre-existing emails that were on my test wiki). There's certainly more that could be done with normalizations (IDN is mentioned above, etc) But at the basic level, if you type your exact letter for letter email address in the login box, it should be able to find it in the system > > > *Type an email in special:contributions. You can now given an email, associate > > a user with that email. That's a bad thing (emails are supposed to be secret). > > This point is very very important. But from what you said, I am sure that if > you reviewed the patch, you did not test it! > > As said in previous discussions, if you enter an email instead of a username in > Special:UserContribution, you get nothing: > ------------------------ > User contributions > For Brouard@ined.fr (talk | block log | uploads | logs) > Search for contributions Show contributions of new accounts only > IP address or username: Namespace: Deleted only > > Only show edits that are latest revisions > > From year (and earlier): From month (and earlier): > > No changes were found matching these criteria. > ------------------- > > but if you enter the name "Nicolas Brouard" you get: > > ------------------- > (Latest | Earliest) View (newer 50 | older 50) (20 | 50 | 100 | 250 | 500) > > 12:29, 1 November 2011 (diff | hist) Talk:62 (Zeugungsunfähigkeit) (top) > 09:06, 10 October 2011 (diff | hist) N Category:Term of the second edition > of the multilingual demographic Dictionary (redirect) (Some explanations) > (top) > 23:25, 24 September 2010 (diff | hist) Template:NewTextTerm (top) > 18:55, 24 September 2010 (diff | hist) m Category:To be checked (top) > 18:30, 24 September 2010 (diff | hist) Category:To be checked (Which > pages should I check?) > 18:26, 24 September 2010 (diff | hist) m Category:To be checked (→Summary > of parameters of NewTextTerm or TextTerm) > > -------------- Different behaviour was obtained on my test wiki. > > > Marking patch as reviewed do to the above mentioned issues. > > Needs probably tests and not only reviews. I can provide logins if somebody > want to test the patch. > > Regards
(In reply to comment #14) > By doesn't actually work I do mean doesn't actually work. My email address on > my test wiki install is bawolff@localhost. Typing "bawolff@localhost" in to the > log in box does not log me into the account, as this patch looks for user's > with the address "Bawolff@localhost" (I also tried an account with an email > address containing underscores which failed for similar reasons. These were not > bad examples meant to make the patch fail. These were the pre-existing emails > that were on my test wiki). @localhost can't be considered as a valid email, at least not for a user but for a developper ok. But the patch works, you can't authenticate this way but need your real username. The patch is valid for MOST users, not all I agree. What I understand from your Bawolff@localhost address is that you have a Linux account on the Wikipedia servers. Would it be possible to process the mysql test of my Comment #9? With its result we could refine our estimation of what MOST means (suppressing also addresses @localhost) and thus have a better of how many wikipedians users could benefit of such a patch. > > There's certainly more that could be done with normalizations (IDN is mentioned > above, etc) But at the basic level, if you type your exact letter for letter > email address in the login box, it should be able to find it in the system OK for the underscore which did not pass the getText! No time yet to propose to let raw email be directly tested by mysql. > > > > > > *Type an email in special:contributions. You can now given an email, associate > > > a user with that email. That's a bad thing (emails are supposed to be secret). > > > > This point is very very important. But from what you said, I am sure that if > > you reviewed the patch, you did not test it! > > > > As said in previous discussions, if you enter an email instead of a username in > > Special:UserContribution, you get nothing: > > ------------------------ > > User contributions > > For Brouard@ined.fr (talk | block log | uploads | logs) > > Search for contributions Show contributions of new accounts only > > IP address or username: Namespace: Deleted only > > > > Only show edits that are latest revisions > > > > From year (and earlier): From month (and earlier): > > > > No changes were found matching these criteria. > > ------------------- > > > > but if you enter the name "Nicolas Brouard" you get: > > > > ------------------- > > (Latest | Earliest) View (newer 50 | older 50) (20 | 50 | 100 | 250 | 500) > > > > 12:29, 1 November 2011 (diff | hist) Talk:62 (Zeugungsunfähigkeit) (top) > > 09:06, 10 October 2011 (diff | hist) N Category:Term of the second edition > > of the multilingual demographic Dictionary (redirect) (Some explanations) > > (top) > > 23:25, 24 September 2010 (diff | hist) Template:NewTextTerm (top) > > 18:55, 24 September 2010 (diff | hist) m Category:To be checked (top) > > 18:30, 24 September 2010 (diff | hist) Category:To be checked (Which > > pages should I check?) > > 18:26, 24 September 2010 (diff | hist) m Category:To be checked (→Summary > > of parameters of NewTextTerm or TextTerm) > > > > -------------- > > > Different behaviour was obtained on my test wiki. Could you detail what you get. I am curious. Regards,
> > @localhost can't be considered as a valid email, at least not for a user but > for a developper ok. But the patch works, you can't authenticate this way but > need your real username. > > The patch is valid for MOST users, not all I agree. What I understand from your > Bawolff@localhost address is that you have a Linux account on the Wikipedia > servers. Would it be possible to process the mysql test of my Comment #9? With > its result we could refine our estimation of what MOST means (suppressing also > addresses @localhost) and thus have a better of how many wikipedians users > could benefit of such a patch. The @localhost part is unimportant. Its the fact that my email started with a lowercase 'b', not an uppercase 'B' that made things not work. I imagine its quite common for people to start their email with a lowercase letter (The user part of an email is of course n theory case-insensitive, but the db stores it in a cases sensitive manner) > > > > > > There's certainly more that could be done with normalizations (IDN is mentioned > > above, etc) But at the basic level, if you type your exact letter for letter > > email address in the login box, it should be able to find it in the system > > OK for the underscore which did not pass the getText! No time yet to propose to > let raw email be directly tested by mysql. > > > > > > > > > > *Type an email in special:contributions. You can now given an email, associate > > > > a user with that email. That's a bad thing (emails are supposed to be secret). > > > > > > This point is very very important. But from what you said, I am sure that if > > > you reviewed the patch, you did not test it! > > > > > > As said in previous discussions, if you enter an email instead of a username in > > > Special:UserContribution, you get nothing: > > > ------------------------ > > > User contributions > > > For Brouard@ined.fr (talk | block log | uploads | logs) > > > Search for contributions Show contributions of new accounts only > > > IP address or username: Namespace: Deleted only > > > > > > Only show edits that are latest revisions > > > > > > From year (and earlier): From month (and earlier): > > > > > > No changes were found matching these criteria. > > > ------------------- > > > > > > but if you enter the name "Nicolas Brouard" you get: > > > > > > ------------------- > > > (Latest | Earliest) View (newer 50 | older 50) (20 | 50 | 100 | 250 | 500) > > > > > > 12:29, 1 November 2011 (diff | hist) Talk:62 (Zeugungsunfähigkeit) (top) > > > 09:06, 10 October 2011 (diff | hist) N Category:Term of the second edition > > > of the multilingual demographic Dictionary (redirect) (Some explanations) > > > (top) > > > 23:25, 24 September 2010 (diff | hist) Template:NewTextTerm (top) > > > 18:55, 24 September 2010 (diff | hist) m Category:To be checked (top) > > > 18:30, 24 September 2010 (diff | hist) Category:To be checked (Which > > > pages should I check?) > > > 18:26, 24 September 2010 (diff | hist) m Category:To be checked (→Summary > > > of parameters of NewTextTerm or TextTerm) > > > > > > -------------- > > > > > > Different behaviour was obtained on my test wiki. > > Could you detail what you get. I am curious. I got the exact same output of Special:Contributions with my email as I would have if I inputted my User name.
When replying to the previous comment, please trim everything but the bit you are replying to. Thanks!
(In reply to comment #15) > (In reply to comment #14) > > > By doesn't actually work I do mean doesn't actually work. My email address on > > my test wiki install is bawolff@localhost. Typing "bawolff@localhost" in to the > > log in box does not log me into the account, as this patch looks for user's > > with the address "Bawolff@localhost" (I also tried an account with an email > > address containing underscores which failed for similar reasons. These were not > > bad examples meant to make the patch fail. These were the pre-existing emails > > that were on my test wiki). > > @localhost can't be considered as a valid email, at least not for a user but > for a developper ok. But the patch works, you can't authenticate this way but > need your real username. > > The patch is valid for MOST users, not all I agree. What I understand from your > Bawolff@localhost address is that you have a Linux account on the Wikipedia > servers. Would it be possible to process the mysql test of my Comment #9? With > its result we could refine our estimation of what MOST means (suppressing also > addresses @localhost) and thus have a better of how many wikipedians users > could benefit of such a patch. > It's not only valid for developers (although that's the most common scenario). You could have all of your e-mail inside your company in the form of user@some-host-without-a-tld. If this is going to be accepted, it should follow the same rules of isValidEmailAddr() or whatever we call it these days, not just e-mails in user@foo.tld form.
>I'm not really a fan of this idea. It just seems wrong (in a gut feeling kind >of way; Don't really have a logical reason) to use email as a log in >credential. Well actually, here is my more rational reason [note, part of this is repeating things other people have said]. MediaWiki assumes emails are: * Not unique * Secret I doubt its possible to maintain these two assumptions, and use them as a login credential. At best you could maybe only reveal other people with the same email address to a person who has proven they know the password to one of the accounts with the email given. Even that seems icky, albeit perhaps acceptable as most accounts with same email belong to same person (Generally that happens for people with bot accounts, or accounts they use only in internet cafes). --- What about using the user id as an alternative login credential. I could log in to wikipedia by putting "#108308" into the username box, and my pass in the password box. Some other parts of mediawiki already support #<user_id> in place of username. (Like Special:Userrights. However, special:unblock does use that syntax to mean something else) The downside to this approach would be: *User's generally have their email memorized already. Once someone is having trouble logging in, its too late to tell them "go to special:preferences and look up your id" *user id's are hard to memorize compared to emails. *Its unclear if there is a good way to inform/advertise to the user that they can log on with their user id. Cheers, Bawolff
(In reply to comment #16) > The @localhost part is unimportant. Its the fact that my email started with a > lowercase 'b', not an uppercase 'B' that made things not work. I imagine its > quite common for people to start their email with a lowercase letter (The user > part of an email is of course n theory case-insensitive, but the db stores it > in a cases sensitive manner) No. The theory says they aren't case insensitive. You should lowercase the domain part, but you shall not touch the user part as only th final mail server knows how to map it (although all of them are case insensitive in practise). Thanks for testing the patch, Bawolff.
Sorry for my late response, I was far from Internet... I have had more time to test your remarks on a standard mediawiki installation with standard wikidb and no special authentication, like CentralAuth or LDAP or whatever, just standard login and password, a Linux box with mysql. And I can certify (and can provide test logins to who want to test the patch) that: - 1 - Special:UserContribution works as I said, it doesn't reveal the Username if you entered an email (it outputs no contribution). - brouard@localhost works. If it did not work, it probably means that you have another username with the same e-mail address and that you did not enter the corresponding password. Currently (and I thank you for this remark) because Username entered with underscores are tested without underscore (I don't understand the reason) an e-mail containing an underscore is not recognized with the current patch (the variable $name has already all underscores replaced by blanks). A solution consists in replacing the blanks in the email address by underscores: $dbr = wfGetDB( DB_SLAVE ); $s = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_name' => $nt->getText() ), __METHOD__ ); if ( $s === false ) { //Start Patch $result = null; $name_= strtr($name, " ","_"); if( Sanitizer::validateEmail($name_)) { $stwo = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_email' => $name_ ), __METHOD__ ); if ( $stwo === false ) { $result = null; } else { $result = $stwo->user_id; } } else { $result = null; } //End patch } else { $result = $s->user_id; } I just tested on a few users and it seems to work, even for n_brouard@localhost . Regards,
Hi, No activity since a month... I think that the only argument against this patch could be that it reveals the name of a user. As I said a Special:UserContribution doesn't DIRECTLY reveal, on the listing, the name of the user when you enter the e-mail address instead of the username. And you get the message below "No changes were found matching these criteria" instead of the list of contribution that you will get if you entered the usernale: --------------Results of Special:UserContribution with the patch above ---- User contributions For Brouard@ined.fr (talk | block | block log | uploads | logs | deleted user contributions | user rights management) Search for contributions Show contributions of new accounts only IP address or username: Namespace: Deleted only Only show edits that are latest revisions From year (and earlier): From month (and earlier): No changes were found matching these criteria. ---------------------------- End of listing ------------------------------ But if you have your mouse on talk or block or etc., you get the Username in clear. Also on Special:Log if you enter an e-mail and if this user is a admin and has changed something special enough to be logged, the list is unfortunately revealing his name! Thus, I agree that, unfortunately, this simple patch is not convenient for Wikipedia! But for many corporate mediawikis where official identity is the rule, I am still wondering if it is a good idea or not? Would spy-robots try to reveal e-mails of Officials? On our own 'patched' wikis, an Arabic user was recently very happy to change his English transliterated name with his Arabic identity but still appreciated the facility to enter his English transliterated e-mail for authentication. I am not sure that the pro is balancing the con (unfortunate weakness that could reveal the email address from an identity) and thus I am disappointed by the leak of my patch. Other issues discussed here, like the very nice Narayam extension, are not as simple as this patch and might still discourage people to sign with their mother language identity. Currently most scientists want to sign with their English transliterated name signature but not all of them if a possibility was offered to sign with their own identity. We recently have had a meeting on Multilingualism in Sciences (mostly social sciences) and it was clear that if the results of Science have to be diffused among the populations, scientists have also to share their results using local languages and signatures! Unicode gives us the opportunity to keep that diversity. Someone, at this humble meeting, remembered us the diversity, which was standard before the second war, by highlighting a scientific review were articles were written in Italian, German, English and French. She also presented a scan of a communication from a Chinese statistician were the hand-written captions and headers of tables were also translated into French and not only Chinese. Would the forced English transliteration period last only a few decades? There are probably other places to discuss that. But we should admit that this future is very dependent of softwares (Mediawiki?) and standards (Unicode) as well as hardwares (virtual keyboards of recent smart-phones are offering 8 different Chinese input methods for example). Would Mediawiki wait until all keyboards are virtual?
Actually, it seems easier to provide a virtual keyboard for those cases. Sure, it can be cumbersome to type your username there, but as the case where you have a non-native keyboard should be uncommon, it seems acceptable. PS: if you are still trying to get that patch accepted, you should provide an updated one (although I don't like that approach, either).
By the way, Nicolas, you should probably get developer access to make submission of future patches easier: https://www.mediawiki.org/wiki/Developer_access
Thanks for your recent comments. As I said, I think that this patch cannot be accepted for Wikipedia because it may reveal the identity of an e-mail. But for a corporate Wiki as for any, more or less, private Wiki it is can be accepted routinely and is very useful. It is also a very simple patch which will probably last long without any change. I will provide an updated patch when I am back to France. Being currently in Taiwan, I realize how important it might be for Asian scientists to get two signatures, one in Chinese and another in transliterated English. The authentication via an e-mail lets you have the choice of adopting Chinese in your signature.
Created attachment 10703 [details] Patch for allowing user_name OR user_email authentication Patch of the proposed solution. Works fine for corporate MediaWiki installations. Pro: Lets you enter your email for login authentication. If successful your are logged as if you entered your username. Cons: Somebody could try to look at the contribution of somebody by entering her e-mail and could determine her username. Conclusions: Very useful for corporate Wiki where the link between e-mail and official username hasn't to be "strictly" hidden. For Wikipedia where people are using pseudos and sometimes many different pseudos, this patch is not appropriate. The aim of this patch is to permit users to sign articles with their Unicode standard signature (username) and not their English-transliterated signature. An email address is easier to enter than a complex input method which may not exist on many standard devices. Without this patch, corporate wikis tend to force people using an English transliterated signature for their username.
Doesn't look too bad. I see a number of coding style issues: use tabs not spaces for identation, place spaces around text in brackets. Don't include Start Patch / End patch markers. The translations are not needed at all, but as you already have them, it can probably be imported on translatewiki. My main concern is that you're implementing this in User::idFromName(). I'd move that logic to a new function User::idFromEmail() or User::idFromEmailOrName() I'd probably make a User::newFromEmail() and call that on SpecialUserlogin.php line 533 if what was provided is an email. For User::newFromEmail() you can just copy loadFromDatabase() with a different select condition. It will only be happning on login, so we can load the full row at once. Also, a new function would fix the case where the email isn't a safe title (and it gets rejected in line 480, before checking the email).
Would your solution solve the identity problem? It is not clear from what you are saying. And if it doesn't, it can't be accepted for Wikipedia. And it is useless, at least for me and probably other people, to enter a more complex patch which I will be unable to follow in the future. I am quite sure that with this simple patch, I can upgrade much more easily for the next few years. But feel free to go further if you want. I already spent some time to move from svn to git (recompiling the rpm with git 1.7.6) and can't spend more time, sorry. You can close the bug if no one is interested.
(In reply to comment #28) > Would your solution solve the identity problem? It is not clear from what you > are saying. I'm proposing some changes to use it only on login. Thus greatly reducing the email -> username disclosure surface, and slowly getting acceptable for upstream. As far as the failure doesn't show the account as existing (ie. «There is no user account with that email or the provided password is wrong»), it could go in. OTOH, we could not make it available for the username field of «forgotten password». We can't reveal if random emails exist or not.
What to do with an email-revealing attack where Eve changes his email to the testing one, and then tries to login with that email to verify if it's rejected, and thus there's another user with that email? It would be very noisy for email-enabled wikis, though. An alternative could be to deny login for emails shared by multiple accounts. That's a denial of service when you don't remember your username or are trapped in a foreign keyboard, but seems marginal. Moreover, the 'attacked' one can easily get control of the accounts...
Created attachment 11587 [details] UniversalLanguageSelector Screenshot I admit that I didn't read the entire report, but isn't this about to be solved by UniversalLanguageSelector and its options to choose both languages and input methods? See the screenshot from translatewiki.net. More info: http://www.mediawiki.org/wiki/Universal_Language_Selector
The Universal Language Selector project looks promising... It is beyond our current need which can be summarized as followed: - be allowed to login with an e-mail (and password); - be logged with a username which can contain any professional name, either an English transliterated name or a 'natively written' name using unicoded characters and not only ASCII or iso-8859-x characters. We are using this patch since a few months now with great success: - some users prefer to be logged and signed with a Korean, Nepali or Thai or Russian etc. name; - some others prefer to keep their English transliterated name, it depends. But ALL prefer to login with an e-mail than with a username (they are forgetting very rapidly the exact spelling when they want to sign with a complete professional name). Sometimes you don't have access to your own keyboard (and are reluctant to follow the various menus choosing the right language and input method) and only need to login (by entering your email) and participate to an English discussion for example (but sign with your Korean or whatever scripted username). This very simple patch concerns multilingual sites which are not concerned by revealing the identity of their users. With this patch you can't discover 'visually' the link between a username and its e-mail address but you could build robots which would reveal them. Thus, it is not appropriate for Wikipedia sites (or needs further developments) but very appropriate for corporate MediaWiki sites.
(In reply to Nicolas Brouard from comment #32) > The Universal Language Selector project looks promising... As for input method editors, it was enabled on all wikis in July 2013 (though not enabled by default on en.wiki).
