As a stopgap solution to T72901, an 'editcontentmodel' user right was introduced in https://gerrit.wikimedia.org/r/#/c/176160/ and made required for changing a page's content model or creating a page with a content model different from the namespace default. We should address the security issues identified in the original bug and remove the user right, so that features that rely on being able to change the content model would work.
- Mentioned In
- T92795: Users without 'editcontentmodel' user right cannot create MassMessage delivery lists
- Mentioned Here
- T49456: VisualEditor: VE should not become active on non-wikitext ContentHandler-type
T72592: Implement a user interface to change a page's content model when $wgContentHandlerUseDB = true;
T73163: Cannot edit old revisions if the content model of those revisions are different from the page's current revision
T92795: Users without 'editcontentmodel' user right cannot create MassMessage delivery lists
T72901: Users can change the content model of other users' user pages to CSS or JS
I briefly read through T72901: Users can change the content model of other users' user pages to CSS or JS and I'm not sure I understand why a separate user right was implemented here. It looks like @Jackmcbarn tried to raise a concern about this as well.
My particular interest in this issue comes from the fact that this issue is seemingly blocking MassMessage's new ContentHandler-supported subscription pages from being used on Wikimedia wikis (T92795).
It's not just a security issue; it's a usability issue. There isn't any sort of UI associated with changing the content model for a given page (T72592), nor (that I'm aware of) is there any mechanism for limiting which namespaces can have which content models (no Phab task yet, but probably should be). Trying to undo the edit which introduces the new content model fails with an exception (T73163). I'm going to guess that no one really knows what happens when someone tries to launch VisualEditor against a non-wikitext page, but we'd need to test that before allowing this in a namespace where VE is turned on. The feature needs a lot more polish before being deployed on a widespread basis. @daniel has even suggested in one thread (somewhere) that this should never be done by an end user, but instead be done via handler-specific code.
This is the first I'm hearing of MassMessage being blocked, so I've started asking questions in T92795. I think it should be possible to get the new version of MassMessage unblocked without having to resolve all of the problems I've identified above.
Oh good! Glad to be wrong about that one. That gives me some hope that all the various gadgets, etc also take content model into account, since the css/js case has been around for a while.
ContentHandler::canBeUsedOn() allows contenthandlers to limit what namespaces or even pages they can be enabled on. Only Flow, SecurePoll, Wikibase, and Gadgets 2.0 implement it though.