NL.png

Developer log #7 :: WSPermissions

WSPermissions is a MediaWiki extension that Wikibase Solutions is currently developing. It will allow administrators to manage read-and-write access to the wiki on a per-page basis. The current system in use at Wikibase Solutions for managing access is one called Lockdown. Lockdown works great for some cases, but is very limited in others. For instance, it is not possible to change permissions through the wiki itself. Furthermore, it only allows you to specify the permissions per namespace, per group. A simple to use, robust, and more flexible system needed to be designed to make MediaWiki a viable option for enterprises seeking an open-source content services platform.


Wikibase Solutions is currently developing an extension that addresses the shortcomings of Lockdown. The upcoming WSPermissions extension will allow administrators to create permission policies for pages in the wiki.


A permission policy consists of one or more rules that determine whether or not a user has access to a page. Some examples of a rule are:

  • Allow users [Marijn, Charlot]
  • Deny members of group [blocked, disabled]
  • Deny when the moon is full


Rules are processed in order and are always processed fully. Therefore, the last rule that matched will determine whether or not the action the user requested to execute is allowed. If no rules matched, the access will be determined based on the fallback rule.

Example

We create a permission policy for the page "Main Page":

  • Allow users [Marijn, Charlot]
  • Deny members of group [blocked, disabled]
  • Deny when the moon is not full

Now say, "Marijn", who is not in any group, wants to visit the Main Page. He matches the first rule, so the software marks him as "allowed". He doesn't match the second rule so he is still marked as "allowed". Unfortunately for Marijn, the software looks outside and notices the moon is currently not full so the software marks him as "denied". Since it is the last rule, the software returns its final verdict: "denied". Marijn is not able to read the page.

Policy inheritance

Creating a separate policy for each page is cumbersome and not very fun. To solve this problem, the extension will feature policy inheritance. Policy inheritance allows you to create a hierarchy of policies. This can be used to combine and reuse policies that are applicable to more than one page. Inheritance allows you to create policies that are built upon existing policies. We can see this in action in this example:


We create a new permission policy for the page "Draft:Main Page". This policy should allow anyone who is able to see the "Main Page" to also view the draft, as well as allowing members of the group "drafter" to view the draft. What we could do is copy the rules from "Main Page" and add one more rule, but this is not ideal: if the policies of the "Main Page" change, the "Draft:Main Page" policy is not updated and we might have caused a information leak! The other, much better option is to inherit the rules from "Main Page":

  • [Inherited rules from "Main Page"]
  • Allow members of group [drafter]

Now, any change to the rules for the "Main Page" is immediately applied to "Draft:Main Page" as well.

Lua error: bad argument #1 to 'mw.text.jsonDecode' (string expected, got nil).