(this is only an idea, and actually contains multiple things to do)
Purpose:
- Reduce the database footprint (especially once we have many temporary users)
- Avoids locking the user table every time there is an edit (for user_editcount, cf rECAU886ec32e351b4534485a9a74392287b87c85e849)
- Decoupling password and email from user table will allow them be provided by third party extension (such as PluggableAuth) - this is also the case of SUL wikis, where password and email can be provided by CentralAuth
- Conceptually local password is only one of auth methods, which should not be part of user
- Resolve T104500: Old versions of sensitive user data (email, password hashes) can remain in database indefinitely due to local and global DB not being kept in sync
| Field | New table |
|---|---|
| user_id | kept |
| user_name | kept |
| user_real_name | user_properties (see T306248) |
| user_password | user_password |
| user_newpassword | user_password |
| user_newpass_time | user_password |
| user_email | user_email |
| user_touched | kept |
| user_token | user_token (optional, potentially with T65354?) |
| user_email_authenticated | user_email |
| user_email_token | user_email |
| user_email_token_expires | user_email |
| user_registration | kept |
| user_editcount | user_editcount |
| user_password_expires | user_password |
| user_is_temp | kept |
This introduces 4 (or 3) new tables: user_password, user_email, user_editcount and (potentially) user_token.
Note:
- user_password, user_email should never have rows for temporary accounts and system accounts; user_token should never have rows for system accounts.
- In Wikimedia projects user_password, user_email (and potentially user_token) table should be empty (but potentially contains some rows for non-SUL accounts for now) since passwords and emails should be managed via CentralAuth
- user_editcount will only have rows for users with edits (so lacking a row implies an edit count of zero). Since 90% of Wikimedia accounts have no edits this table will be significantly smaller than user table. If we have an index of this table it may also solve T344782: New special page to list users by highest edit count.
- we need to first migrate local emails to CentralAuth
- currently CentralAuth does not provides an email address confirmation mechanism, and we need to make one
- optionally I also propose to split the email and password related fields of CentralAuth globaluser to new tables, to reduce the database footprint of temporary users