Hi,
re: the new email authentication in 1.5: I assume it will be necessary for a user to authenticate themselves on every wiki on which they have an account to use email features on that wiki. For Wikimedia, where many people have accounts on a dozen wikis or more, that might be a major PITA. I would suggest disabling this until we have single login -- unless someone is willing to hack it so that a single authentication will take effect for all wikis.
Best,
Erik
Erik Moeller schrieb:
re: the new email authentication in 1.5: I assume it will be necessary for a user to authenticate themselves on every wiki on which they have an account to use email features on that wiki. For Wikimedia, where many people have accounts on a dozen wikis or more, that might be a major PITA. I would suggest disabling this until we have single login -- unless someone is willing to hack it so that a single authentication will take effect for all wikis.
I only can say again: http://meta.wikipedia.org/wiki/SUL -- single user login is a long-wanted, one user database for common unique name and user accounts a must.
The Mediawiki page shows the three most important proposals.
Is Kate's namechecker http://meta.wikimedia.org/wiki/Namecheck again available ? Kate had programmed a neat tool, with which those accounts with the same certain name accross all wikis could be identified. In addition, those with the same stored e-mail address where also indentified by same numbers... it was a really nice tool and a kind of pre-requisite for SUL
Perhaps it would be clever to delay the work towards release 1.5 and to concentrate on this long-wanted SUL ? T.
Thomas Gries wrote:
Perhaps it would be clever to delay the work towards release 1.5 and to concentrate on this long-wanted SUL ? T.
Lots of things are long-wanted. 1.5 needs to go live ASAP for performance reasons. Anyway, the code for SUL was written and released in 1.4, the only thing missing is a conversion script and a sysadmin brave enough to apply it. So there's no need to tie it to the release cycle. The email authentication problem can be solved in some other way, such as marking all existing email addresses authenticated.
-- Tim Starling
Tim Starling schrieb:
Thomas Gries wrote:
Perhaps it would be clever to delay the work towards release 1.5 and to concentrate on this long-wanted SUL ? T.
Lots of things are long-wanted. 1.5 needs to go live ASAP for performance reasons. Anyway, the code for SUL was written and released in 1.4, the only thing missing is a conversion script and a sysadmin brave enough to apply it. So there's no need to tie it to the release cycle. The email authentication problem can be solved in some other way, such as marking all existing email addresses authenticated.
Tim:
better use the switch I had introduced ;-))
in DefaultSettings.php simply set
$wgEmailAuthentication = false;
This means, that the database is left untouched, the feature is disabled. Later, when SUL works, set it to true, and the addresses can be authenticated by the users at their discretion. (When a user needs a temporary password - because s/he forgot the regular one - the wiki sends also to unconfirmed addresses. Only the "higher" e-mail functions e-mail user and e-mail notification only sends to confirmed addresses if the switch is set to "true")
Tom
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Tim Starling wrote:
Anyway, the code for SUL was written and released in 1.4, the only thing missing is a conversion script and a sysadmin brave enough to apply it. So there's no need to tie it to the release cycle. The email authentication problem can be solved in some other way, such as marking all existing email addresses authenticated.
If my taking the heat for applying it will be helpful, then once there is a conversion script and someone feels it is probably ready to run, then I am happy to say "Let's run it now" so that if/when people's heads explode I can be the one to blame.
--Jimbo
Jimmy Wales wrote:
Tim Starling wrote:
Anyway, the code for SUL was written and released in 1.4, the only thing missing is a conversion script and a sysadmin brave enough to apply it. So there's no need to tie it to the release cycle. The email authentication problem can be solved in some other way, such as marking all existing email addresses authenticated.
If my taking the heat for applying it will be helpful, then once there is a conversion script and someone feels it is probably ready to run, then I am happy to say "Let's run it now" so that if/when people's heads explode I can be the one to blame.
I'm not sure what Tim is referring to.
There's support for using a shared user table for multiple wikis; that can't be used for our sites as it came two years or so too late. Accounts are already established separately on each wiki which can't be automatically resolved in a clean way, so this has never been an option.
There's support via the AuthPlugin interface for a global account system as an overlay, but we don't yet have a suitable infrastructure for it to plug in to or a migration interface (which would be user-driven, allowing them to resolve most conflicting accounts without intervention from sysadmins).
So no, we don't have something that can just be run and magically make things happen unless somebody's been hiding it.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
I'm not sure what Tim is referring to.
There's support for using a shared user table for multiple wikis; that can't be used for our sites as it came two years or so too late. Accounts are already established separately on each wiki which can't be automatically resolved in a clean way, so this has never been an option.
Yes it can. We've talked about conflict resolution methods before. We merge accounts that are the same person, remove clashing accounts that have no contributions and for the small percentage of genuine clashes, I've suggested allocating them on a first-come first-served basis and requiring the others to change their name. Others have suggested giving the name to the person who most deserves it, as judged by some as yet unspecified process involving discretion.
This is why JeLuF split off the user_rights table, so that we could implement shared usernames but have permissions local to each wiki.
It's not clean, but it's not impossible. And in the long term it will leave us with a very good user experience. As I said, it requires conversion software and system administrator bravery.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim Starling schrieb:
Brion Vibber wrote:
I'm not sure what Tim is referring to.
There's support for using a shared user table for multiple wikis; that can't be used for our sites as it came two years or so too late. Accounts are already established separately on each wiki which can't be automatically resolved in a clean way, so this has never been an option.
Yes it can. We've talked about conflict resolution methods before. We merge accounts that are the same person, remove clashing accounts that have no contributions and for the small percentage of genuine clashes, I've suggested allocating them on a first-come first-served basis and requiring the others to change their name.
So I'm user "Magnus Manske" on en, de, meta, and I-don't-know-what. Suppose someone created a user "Magnus Manske" (unlikely for that name, but anyway;-) on, say, the French wikipedia, a week ago. He has edited three articles since then. He sees the new user system a minute before me and signs on. So he gets to keep the "Magnus Manske" user and I'll have to change my user name?
Frankly, I don't think so.
Image Lir, signing on as "Jimbo Wales" on some mostly usused wikipedia, with a little luck getting that user name officially. Or as Brion Vibber or Tim Starling. Granted, that's extreme, but even without malicous users doing "user name squatting", first-come first-serve strikes me as a recepie for chaos.
I think I suggested this some time ago, but here it goes again: * Create "global" users for all unique user names in wiki(pedia)-land * Merge all users which carry same name and password hash (and maybe email), where all instances across wiki-land match perfectly * Block creation of all conflicting user names, both locally and globally * Work the conflicting ones out one-by-one manually, while keeping them active locally
This seems like the only fair way to me.
Magnus
On Mon, 6 Jun 2005, Magnus Manske wrote:
I think I suggested this some time ago, but here it goes again:
- Create "global" users for all unique user names in wiki(pedia)-land
- Merge all users which carry same name and password hash (and maybe
email), where all instances across wiki-land match perfectly
- Block creation of all conflicting user names, both locally and globally
Are there any stats on how many conflicting usernames are in the db? Is it possible to run some query on the user tables? If we only have 10 conflicting accounts, going manually is a workable strategy. Not if we have 20,000.
Alfio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alfio Puglisi schrieb:
On Mon, 6 Jun 2005, Magnus Manske wrote:
I think I suggested this some time ago, but here it goes again:
- Create "global" users for all unique user names in wiki(pedia)-land
- Merge all users which carry same name and password hash (and maybe
email), where all instances across wiki-land match perfectly
- Block creation of all conflicting user names, both locally and globally
Are there any stats on how many conflicting usernames are in the db? Is it possible to run some query on the user tables? If we only have 10 conflicting accounts, going manually is a workable strategy. Not if we have 20,000.
Even with 20,000 initial conflicts, it would be quite possible. IMHO many/most conflicts will be with user names that were created a year ago and used once, with no user page.
Then maybe some accounts created by the same user, with different passwords or emails.
Come on, a community that created two million encyclopedia articles could merge 20,000 user accounts in an instant ;-)
(though I strongly doubt there are as many as 20,000).
Magnus
Would it be possible to give username priority first to sysops, then by number of accounts owned across different wikis, then most recent edit activity, and finally date of first registration?
or some combination of these.
That should reduce the number of conflicts to almost zero.
Paul
On 6/6/05, Magnus Manske magnus.manske@web.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alfio Puglisi schrieb:
On Mon, 6 Jun 2005, Magnus Manske wrote:
I think I suggested this some time ago, but here it goes again:
- Create "global" users for all unique user names in wiki(pedia)-land
- Merge all users which carry same name and password hash (and maybe
email), where all instances across wiki-land match perfectly
- Block creation of all conflicting user names, both locally and globally
Are there any stats on how many conflicting usernames are in the db? Is it possible to run some query on the user tables? If we only have 10 conflicting accounts, going manually is a workable strategy. Not if we have 20,000.
Even with 20,000 initial conflicts, it would be quite possible. IMHO many/most conflicts will be with user names that were created a year ago and used once, with no user page.
Then maybe some accounts created by the same user, with different passwords or emails.
Come on, a community that created two million encyclopedia articles could merge 20,000 user accounts in an instant ;-)
(though I strongly doubt there are as many as 20,000).
Magnus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCpAdACZKBJbEFcz0RAsceAJ9XCIZkVYHeTUc9zJCXkIrUkDi3KwCeMXaP FY2PxZ2KrUNuf702SaD7Bsk= =BDsA -----END PGP SIGNATURE----- _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Magnus Manske wrote:
So I'm user "Magnus Manske" on en, de, meta, and I-don't-know-what. Suppose someone created a user "Magnus Manske" (unlikely for that name, but anyway;-) on, say, the French wikipedia, a week ago. He has edited three articles since then. He sees the new user system a minute before me and signs on. So he gets to keep the "Magnus Manske" user and I'll have to change my user name?
Those cases can be resolved manually, that goes without saying.
-- Tim Starling
Hello Magnus,
Monday, June 6, 2005, 10:49:28 AM, you wrote:
I think I suggested this some time ago, but here it goes again:
- Create "global" users for all unique user names in wiki(pedia)-land
- Merge all users which carry same name and password hash (and maybe
email), where all instances across wiki-land match perfectly
- Block creation of all conflicting user names, both locally and globally
- Work the conflicting ones out one-by-one manually, while keeping them
active locally
This seems like the only fair way to me.
what should I do if someone has different usernames on different wikis? for example username "Monk" on en: is taken by someone (was inactive for a long time). I will be unable to create global user name "Monk" at all, if your proposal is implemented.
It seems not too fair way to me.
monk@zoomcon.com wrote:
what should I do if someone has different usernames on different wikis? for example username "Monk" on en: is taken by someone (was inactive for a long time). I will be unable to create global user name "Monk" at all, if your proposal is implemented. It seems not too fair way to me.
Why is that any less fair than the current situation where you can't create the user "monk" because someone has already taken it?
Hello Magnus,
Monday, June 6, 2005, 10:49:28 AM, you wrote:
I think I suggested this some time ago, but here it goes again:
- Create "global" users for all unique user names in wiki(pedia)-land
- Merge all users which carry same name and password hash (and maybe
email), where all instances across wiki-land match perfectly
- Block creation of all conflicting user names, both locally and
globally * Work the conflicting ones out one-by-one manually, while keeping them active locally
This seems like the only fair way to me.
what should I do if someone has different usernames on different wikis? for example username "Monk" on en: is taken by someone (was inactive for a long time). I will be unable to create global user name "Monk" at all, if your proposal is implemented.
It seems not too fair way to me.
I think this is unresolvable unless we expire old accounts (which would work for you but perhaps not for others where there are two active users with the same name on different wikis). I happen to think it's bad practise to encourage editors to assume that accounts with the same name on different Wikis are held by the same person--there really is not way of being sure unless the editor puts a link to his other accounts on his userpage. This can be validated manually by the reader simply by looking at the history of the userpage to make sure the information was added by the account owner. I think that's good enough for Wiki. Another possibility which would require development work would be to permit editors to list their identities on alternate wikis in preferences. To set this up the editor should be required to validate by entering his password on the foreign wiki, which is then checked by some suitable method (xml-rpc? SOAP? or else screen scraping) on the foreign Wiki, which must be up and running at the time the validation is carried out. Personally I don't think the benefit of this development-heavy solution would justify the cost.
wikitech-l@lists.wikimedia.org