Page MenuHomePhabricator

Fully implement read/view restrictions in mediawiki core
Open, Needs TriagePublicFeature

Description

Proposal:
There should be an option to protect a page from viewing, in addition to the current edit/move/upload/create protection options

Use case in Wikimedia projects:

Background
https://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
https://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_viewing

Acceptance criteria:
Read protection or restrictions should be apply to be applied to a page or a namespace. Users must have the relevant rights to:

  • Export the page
  • View the page, the page history, or the page content
  • Edit the page
  • Move the page
  • The page should either not be transcluded, or the same view restriction should extend to its transclusion

In addition, the feature must work efficiently with any supported types of caches

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
DannyS712 changed the subtype of this task from "Task" to "Feature Request".Aug 17 2019, 11:12 PM

This is also an essential enterprise feature - the WMF will need to implement this anyway if they decide to offer commercial MediaWiki support (see https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Working_Groups/Revenue_Streams/Recommendations/4).

Other use cases include long term abuse documentation, other stuff we use private wikis for (Checkuser, arbcoms) and stuff that should be hidden but is currently public (TitleBlacklist).

Given the need to restrict transclusion as a work-around, and to avoid burdening the caching, I would suggest that read-protected pages not be transcludable at all, rather than only being shown on inclusion if the user has the relevant rights. A first implementation may only allow the protection to be for an entire namespace (intended for extensions adding namespaces), and require that protected namespaces also be part of wgNonincludableNamespaces (per DefaultSettings comment, "Among other things, this may be useful to enforce read-restrictions which may otherwise be bypassed by using the template mechanism.") since as far as I know there isn't currently a way to exclude pages on a page-by-page basis from transclusion.

Izno added a subscriber: Izno.

If I read the task title correctly, this task is about fully implementing read/view restrictions in "mediawiki core". So tagging Platform Engineering for review.

eprodromou added a subscriber: eprodromou.

We think this sounds interesting, but it's not functionality that's on our (CPT's) roadmap at this point. We're putting this in our icebox, but if someone picks up the project and starts moving it forward, we'll start actively tracking it and can provide friendly cheerleading. This level of functionality requires an RFC.

We think this sounds interesting, but it's not functionality that's on our (CPT's) roadmap at this point. We're putting this in our icebox, but if someone picks up the project and starts moving it forward, we'll start actively tracking it and can provide friendly cheerleading. This level of functionality requires an RFC.

RfC created at T249380: RfC: Per namespace view restrictions

Akuckartz raised the priority of this task from Medium to High.Jun 15 2020, 7:00 PM
Aklapper raised the priority of this task from High to Needs Triage.Jun 16 2020, 4:42 AM

@Akuckartz: Do you plan to work on fixing this task, as you increased the priority of this task? If yes then please feel free to set yourself as assignee - thanks!

Aklapper raised the priority of this task from High to Needs Triage.Jun 16 2020, 6:01 AM

@Akuckartz: Could you please reply, instead of reverting changes? Thank you. :)

@Akuckartz: Could you please reply, instead of reverting changes? Thank you. :)

Sorry! No, I currently do not intend to work on it. When will it be triaged?

@Akuckartz: If your question is about the "Priority" field, then maybe whenever someone [plans to] work on this task. I don't see anything here to "triage".