|Page protection as a component|
This RFC describes a potential fix for the spaghetti coupling of MediaWiki core to its security logic.
Make the article protection model easier to maintain and extend.
We should first create a security package, then move functionality in smallish chunks. Each step must be backwards-compatible with existing logic, hook usages, and configuration, and it must be possible to reverse these patches after they have been deployed (ie, no data was harmed).
The current access control system in core is composed of,
- Groups, Roles, and Users, the basic components of user rights. Consider dividing the responsibilities of User code.
- "Protected pages", a feature allowing administrators to lock certain pages against editing or moving, according to role. Protection may be cascaded down to all transcluded pages and templates. This logic is embedded in the Title class and can be moved into includes/security/TitleProtection.
- "Protected titles", a blacklist of titles which are banned and cannot be created. This logic is also embedded in Title code, and should be extracted.
- Out of scope: further layers of protection are implemented by site policy.
Core antivandalism features such as "user and IP blocking" could be moved into its own module, or into "security" with the access control code. It gets murky. Since that particular tool is already encapsulated in the Block class, let's leave it alone.
Followon work to improve security code will be easier once we have extracted the security logic. Next steps could be,
- Granularization of permissions, see MZMcBride ranting quite productively about granularizing permissions.
- The not-to-be-confused with proposal to itemize protection, from 2011.
- Patch for review: Gerrit change 166357
- RFC discussion: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-09-17-21.01.log.html
- Abandoned: Gerrit change 23999 - changes to core
- Abandoned: Gerrit change 24142 - refactored as an extension
- bug 40293- bugtracker for this feature