Page MenuHomePhabricator

Can't authenticate using my mother language username (UNICODE) when I only have (a public) access to Wikipedia with an ASCII (english) keyboard
Closed, InvalidPublic

Description

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,


Version: 1.18.x
Severity: normal
See Also:
T30085: RFC: Allow user login with email address in addition to username
T15097: Deploy ULS/UniversalLanguageSelector to all Wikimedia wikis (tracking)

attachment languagesb181b.patch ignored as obsolete

Details

Reference
bz34590

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:17 AM
bzimport set Reference to bz34590.
bzimport added a subscriber: Unknown Object (MLST).

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

sumanah wrote:

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.

john wrote:

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_freqCOUNT(email_freq)

+------------+-------------------+

13047
222
31

+------------+-------------------+

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.

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.

attachment usernameoremail2.patch ignored as obsolete

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

sumanah wrote:

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.

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.

Attached:

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

Attached:

bug34590.png (657×1 px, 127 KB)

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

Aklapper subscribed.

UniversalLanguageSelector is deployed on all Wikimedia wikis and its input methods support allows entering non-ASCII characters on an ASCII keyboard.
For using an email address instead of a user name, there is T30085. Hence closing this task as there is no software development to track in this task itself.

This task is either a duplicate of T30085 or it is a duplicate of T15097.