Single login specifications
This page is outdated, but if it were updated, it might still be useful. Please help by correcting, augmenting and revising the text into an up-to-date form.
|←Unified login||Unified login|
|single login system. Brion Vibber is committed to this project, though not necessarily this specification. This page is just a proposal; for more information, see the single login documentation page.This page is meant as a set of suggested specifications including work flows and GUI mock-ups for the transition to a|
Stage 0 (Limit conflicts)
- New user creation is updated to check all projects for conflicts, to prevent conflicts from growing in number. This should be done before any big public announcement.
- For instance, if you want to create a new Wikiquote account, you might be asked to pick another wiki on which that username has an account, and authenticate with the password from the other wiki.
Stage I (Estimate conflicts, gather statistics)
- Simple code is implemented to allow accounts on different projects to be linked together.
- A cross-project "you have new messages" banner is implemented. Users are encouraged to identify related accounts, and setting a valid e-mail address in their preferences is the most automatic way to do this (a bot auto-associates same-name same-email accounts; others have to be processed by hand).
- NB: this is functionality that will be needed after any migration, and it is a cool feature that people will want to have at any rate, providing encouragement to identify accounts with one another.
- This is promoted widely. (VP, mailing-list announcements, site-wide notice for logged-in users?)
- After a week of such promotion, statistics are gathered:
- How many accounts are linked, and how many could be (same name/email) but haven't yet had such a link requested?
- How many accounts with the same name have potential merge-conflicts for what is planned in later stages? Two levels of potential conflicts: no email/different email.
- How many users with >500 total edits have a potential conflict?
- How many totally-inactive accounts (no user/talk page, no edits; or a user/talk page, perhaps a redirect, but no email and no article-space edits) are there? Often these have been created to prevent someone else from creating a suspiciously-similar username... A list is made available.
- Should these be allowed to stake claims on the global namespace? It would be more sensible to let users register name-variants on a blacklist, to keep the "list of users" pages clean.
- Ditto for very-few-edit accounts (no email, older than 3 months with no more than 5 total edits). How many such accounts are there? (answer: more than half) What do their contribs usually look like? A profile of this set of accounts would be useful.
- Assuming they won't return, perhaps we can find a good way to preserve their edit history - and let them reclaim their original edits if they do return - without giving them a global username. Note that we will have to find such a method for abandoned accounts that lose a conflict, at any rate.
Stage II (Announcements, make life easy for active users)
- A notice is distributed (sitewide message, other), encouraging users to set a valid e-mail address in their preferences for at least their most active user account. It is pointed out that this is the safest way to keep their current name. It is recommended to use the same e-mail address for each login.
- This migration process is linked to, so everyone knows what to expect.
- A temporary table is created to help with account-merging. Within the set of user accounts from all databases, subsets sharing a name and an e-mail address are identified (including sets of size one).1 The total edit count for each subset is computed. (the edits are not weighted)
- An email is sent to active subsets (>100 edits) with potential conflicts, informing them of the conflicting projects/languages. (Notice A2)
- After a week, a similar notice is sent to all users [with >1 edit?] with potential conflicts -- either via email, if it is set, or as a note appended to their talk page. (Notice A3)
- Any complaints from users who expect to lose a name conflict should start being responded to, with mediation if necessary.
Stage III (Early migration and no-conflict merging)
- A new shared user account (and preferences) table is created.
- Code is added which first checks the shared-account table first for a given name, and checks for a global cookie/identifier, before checking via traditional methods.
- Accounts are migrated to the shared table as follows:
- GROUP 1: If there is only one database with a given name, and it passes a minimum-activity check (more than 1 article-namespace edit? see stats above), it is migrated; with the notification put on its user talk page and possibly emailed. ("E-mail" B1)
- GROUP 1.1: If there is only one subset with a given name, it is not migrated.2 Ownership of this name is assigned to the e-mail address of the subset. An e-mail notification is sent out to this effect, inviting the user to verify that all those accounts are his/hers. (E-mail B1? 2? 3? Perhaps a new email.)
- A talk-page notice is also left on the most active account in the subset.
- A history-preserving patch is written that allows User:A in en:wp and User:B on en:wikt to merge into a global account named "A".
- Perhaps an actual name change with redirects from old userpages... actively moving all "User:B/*" and "User talk:B/*" to "User:A..." Then freeing up the name "B" if possible.
- A patch is written that allows User:Isam on en:wp and User:عصام بايزيدي on ar:wp to share a single universal login.
- Perhaps this would allow a single global-user to have different usernames on different wikis, and to reserve each of them globally. (This could require a special request.)
- Users in the shared table can see two new things:
- A global user-preferences panel.
- A new screen where they can enter a username/password for existing accounts from any Wikimedia database. Any account they successfully authenticate against will be merged into theirs via one of the above methods (with an option for 'merge' and another for 'multiple usernames'... the latter might be a request that needs consideration). This screen should be accessible through the user preferences.
Stage IV (Finishing migration and conflict merging)
- Last call for human-assisted conflict mediation.
- Accounts are migrated to the shared table as follows:
- GROUP 2: If an account name exists in multiple subsets, the subset with the highest edit count "wins". Accounts in that subset are not migrated, however.2 Ownership of this name is assigned to the e-mail address of the subset. An e-mail notification is sent out to this effect, inviting the user to verify that all those accounts are his/hers. (E-mail B2 or B3 as appropriate) [Also a talk-page notice]
- GROUP 3: All remaining accounts - those without an e-mail address, those that never edited, and the losers of GROUP 2 - are not assigned or migrated.
- Announcements, with status updates, are sent out. (Another site-wide notice may be appropriate here.) Every user should be aware that the migration is going to take place, across *all* projects, and what that will mean.
- The migration will not actually take place until Date X (see below; say after a month to allow for replies to the above emails, especially from the smaller, slower-moving communities); mediation of conflicts, and final bugfixes, can finish now.
- After a fixed migration date (Date X), it will no longer be possible to log in with an account that lost a merge conflict.
- All existing login sessions will expire.
- The default login screen will state unambiguously that unless you have received some notification (e-mail or talk page), you will most likely have to create a new account, and that you will be able to migrate your existing accounts to the new system.
- Users in GROUP 1 can log in using their password as they used to.
- Users in GROUP 2 can log in using the password of the account with the highest number of edits.
- Users in GROUP 3 have to create a new account.
- After the first login:
- The entered password will be tested against all existing local accounts with the same name, and all successfully authenticated accounts will be migrated.
- If a local account with the same name but a different password exists, the old local username will be moved to something unambiguous [and reserved?] such as "Name (old: lang-proj)."3
- Users in all groups see a new screen where they can enter a password for their existing accounts from any Wikimedia database. Any account they successfully authenticate against will be merged into theirs. This screen should continue to be accessible through the user preferences.
1 All user passwords are presently hashed and salted. Therefore, no two password hashes across different projects or languages are identical, and passwords cannot be compared at this stage.
2 We must avoid a scenario where a troll account sharing an email address and username with a legitimate account is automatically migrated.
3 There should be some mechanism for retrieving an old account & edit history, if one loses a merge and has the old account renamed; a csv file of all such accounts might suffice.
The ownership locks should expire after 2 months. After this period, users in GROUP 2 become users of GROUP 3. Optionally, e-mail notifications which bounce because of a permanent failure could lead to immediate expiration.
After a transition period of 6 months, all remaining local accounts will be converted to the new system using the account name syntax "Username@wiki", e.g. "Eloquence@wp-en".
- With a global account system, existing signatures on talk pages and in votes may point to the wrong account name after a migration if the user's name has been changed due to losing a conflict. While timestamps provide context, we cannot trivially create redirects, as the user winning the name may also want to edit on the wiki. It may be best to simply ask the winner to provide some disambiguation.
The global account table consists at least of the following fields:
|user_id||int(10) unsigned||This is independent from local IDs|
|user_email_authenticated||varchar(14) binary||We only want to authenticate once|
|user_expires||tinyint(1)||Account name is locked, but account has not yet been claimed by its determined owner. Set to 0 on first login. Global accounts with user_expires=1 will be deleted later so that others can claim them.|
An authentication plugin is written using the AuthPlugin.php class. This plugin checks against the global account database, and creates a local account if no account with that name exists already. The local account will use as its settings those in the global table (function initUser).
A distinction is to be made in Special:Preferences between global settings and local settings. This functionality needs not be there in the first implementation. However, the following functionality should be there:
- E-mail authentication should be checked in the shared table if the e-mail address matches; otherwise we have to authenticate for every account.
- New passwords should be sent to the e-mail address associated with the local account, but be set in the shared account table, unless a password is requested specifically for the purposes of hooking up a local account.
A tinyint(1) user_valid field is added to the user tables for all wikis. This is checked in User::idFromName -- invalid accounts return 0. All existing accounts are marked invalid (0). This prevents false look-ups (global user visits a wiki where their name exists.) Furthermore, MediaWiki is changed to look up user_name in the user table in page histories and other places where it is currently redundantly stored, if the user_id is not 0. This makes it unnecessary to change many rows when a user name is modified.
Scenario 1: User creates a new account
The AuthPlugin checks whether a user with that name exists. This includes locked accounts until the date of expiry. When the user edits a wiki, a local account with is_valid set will be created transparently.
Scenario 2: User or script hooks up existing account from a local wiki that has the same name as global name
The account's is_valid flag is set if the correct password is provided.
Scenario 3: User or script hooks up existing account from a local wiki that has a different name
The account is renamed to the global name using the existing code to do so, and the is_valid flag is set.
Scenario 4: User hooks up an existing account after an is_valid local account with the same name has been created
This scenario occurs when a user creates a global account, but forgets to hook up a local account, and then edits the wiki where that local account exists. It could be avoided by preventing the user from editing the wiki unless they provide a password for that account (if necessary by resetting the password). Otherwise, the account histories have to be merged to the new user ID.
These will be needed to be sent out for various tasks; each user will get at most one of each letter, and possibly (hopefully!) not a D if they have transitioned their local accounts in time.
A: Global transition is coming; be preparedEdit
This should be the third or fourth message about this change, not the first. The early messages about the transition should be well before it begins.
needs more, esp. "go set email addresses on all your accounts"
B1: Simple transition notification (one account)Edit
tell the users not to worry, everything now works as it did before - do we actually need this?