Page MenuHomePhabricator

Remove 'editcontentmodel' user right and restriction on editing content models
Closed, DuplicatePublic

Description

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.

Event Timeline

wctaiwan created this task.Mar 16 2015, 2:08 AM
wctaiwan raised the priority of this task from to Needs Triage.
wctaiwan updated the task description. (Show Details)
wctaiwan added a subscriber: wctaiwan.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 16 2015, 2:08 AM
MZMcBride set Security to None.Mar 16 2015, 2:14 AM
MZMcBride added subscribers: daniel, csteipp.
MZMcBride added a subscriber: MZMcBride.

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.

Broadly, CSS and JavaScript user subpages are a weird special case, so we should probably treat them as such. Is there any reason not to fold content model changing back into the edit user right?

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.

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.

Solved two years ago: T49456: VisualEditor: VE should not become active on non-wikitext ContentHandler-type

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.

Solved two years ago: T49456: VisualEditor: VE should not become active on non-wikitext ContentHandler-type

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.

nor (that I'm aware of) is there any mechanism for limiting which namespaces can have which content models

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.