Extension:WikiGuard

MediaWiki extensions manual

WikiGuard Release status: beta
Implementation	User rights
Description	Advanced permission policy management for MediaWiki
Author(s)	Marijn van Wezel (Wikibase Solutions) (Xxmarijnwtalk)
Latest version	0.2.0 (2023-08-02)
Compatibility policy	Master maintains backward compatibility.
MediaWiki	>=1.35.6
PHP	>=7.4
Database changes	No
Hooks used BeforeParserFetchTemplateAndtitle EditFilterMergedContent getUserPermissionsErrors MediaWikiPerformAction PageRenderingHash SearchableNamespaces SearchGetNearMatchComplete SkinBuildSidebar LoadExtensionSchemaUpdates
License	GNU General Public License 2.0 or later
Download	GitLab: project page git repository URL [help ] commit history Note: No localisation updates are provided by translatewiki.net .

The WikiGuard extension implements an advanced permission policy management system for MediaWiki. It allows you to define so-called permission policies that determine whether a user is allowed to perform a request, and apply these policies to specific actions (view, edit, delete, etc.) globally, on selected namespaces or on selected pages.

Policies in detail

A policy is a set of rules that are evaluated from top-to-bottom to determine whether a request is allowed. A rule consists of two basic parts, the conditional and the consequent. The conditional determines whether a rule matches the given request, and the consequent determines whether the request should be allowed or denied when it does. For example, a rule may take the form of the following if-statement: if the user is an admin then we allow the request. How to write these rules such that WikiGuard can understand it will be discussed in the #Writing policies section below.

Since the rules are evaluated from top-to-bottom, the last rule in the list that matches will be the one that determines whether the request is actually allowed. This means that the order in which the rules appear is relevant. For example, suppose we implement a policy that denies all (logged-in) users, unless they are also in the sysop user group:

• if the user is logged in then deny
• if the user is an admin then allow

If we were to swap these rules, it would no longer work, as the last rule would deny any logged-in user (even administrators).

Default behaviour

By default, if no rules match, the request is allowed. However, since WikiGuard never overrides the default protections of the wiki, the request may still be blocked by MediaWiki or another extension.

Inheritance

Policies inherit the rules of their parent. This means that WikiGuard, for any action, will first evaluate the rules of the policy applied to the entire wiki, then those of the policy applied to the corresponding namespace and finally the rules of the policy applied to the page itself.

For example, if you want to view the main page, it will first evaluate the rules of the wiki-wide view policy (if it exists), then the rules of the main namespace's view policy (if it exists) and finally the rules of the main page's view policy (if it exists).

Writing policies

The wikiguard-edit-policy user right is required to edit policies.

No user interface has been implemented to edit policies yet, which means that you have to edit raw JSON to create or edit a policy (luckily, a JSON schema is provided).

To create or edit a policy, create or edit the appropriate page in the Policy namespace. A policy consists of a (possibly empty) ordered list of rule objects, where each rule object specifies a rule.

Rule objects

A rule object, in its most basic form, has a rule key, specifying the type of the rule (see #Rule types below), and a consequent key, specifying the consequent of the rule (true/false). For example, the rule if the user is an admin then allow would be serialised as such:

{
    "rule": "issysop",
    "consequent": true
}

A rule may require a parameters key, specifying additional parameters for the rule. Which parameters are required and what their type must be differs for each rule. For example, the hasusername rule, which matches if the user is in a list of usernames, requires the username parameter, which must be an array of strings:

{
    "rule": "hasusername",
    "consequent": "false",
    "parameters": {
        "usernames": [
            "Blocked user 1",
            "Blocked user 2",
            "Xxmarijnw"
        ]
    }
}

Additionally, it is possible to specify an alternative key, specifying whether the request is allowed if the rule doesn't match. Finally, it is possible to negate the condition of the rule by setting the negate key to true. For example, the rule if the user is not an admin then deny otherwise allow would be serialised as such:

{
    "rule": "issysop",
    "consequent": false,
    "alternative": true,
    "negate": true
}

Rule types

hasusername

The "has username" rule checks if the current user has one of the specified usernames as their username.

Parameters

usernames : string[]

The usernames to match.

Example

{
    "rule": "hasusername",
    "consequent": true,
    "parameters": {
        "usernames": ["Pietje Bell", "John Doe"]
    }
}

inallgroups

The "in all groups" rule checks if the current user is a member of all the specified groups.

Parameters

groups : string[]

The groups the user must be in.

Example

{
    "rule": "inallgroups",
    "consequent": true,
    "parameters": {
        "groups": ["sysop", "interfaceadministrator"]
    }
}

inanygroups

The "in any groups" rule checks if the current user is a member of any of the specified groups.

Parameters

groups : array<string>

The groups the user may be in.

Example

{
    "rule": "inanygroups",
    "consequent": true,
    "parameters": {
        "groups": ["sysop", "administrator", "developer"]
    }
}

isregistered

The "is registered" rule checks if the current user is a registered user.

Example

{
    "rule": "isregistered",
    "consequent": true
}

issysop

The "is sysop" rule checks if the current user is a member of the group "sysop".

Example

{
    "rule": "issysop",
    "consequent": true
}

lunarphase

The "lunar phase" rule matches based on the current phase of the moon.

Parameters

moonPhase : "full"|"new"|"waxing"|"waning"

The phase the moon must be in.

Example

{
    "rule": "lunarphase",
    "consequent": true,
    "parameters": {
        "moonPhase": "waning"
    }
}

template

The "template" rule parses a template and checks if the returned value is true-ish ("true"/"yes"/"on"/"1").

Parameters

template : integer

The ID of the template to parse.

Example

{
    "rule": "template",
    "consequent": false,
    "parameters": {
        "template": 3827
    }
}

Example

[
    {
        "rule": "template",
        "consequent": false,
        "parameters": {
            "template": 3827
        }
    },
    {
        "rule": "issysop",
        "consequent": true
    },
    {
        "rule": "lunarphase",
        "negate": true,
        "consequent": true,
        "parameters": {
            "moonPhase": "full"
        }
    }
]

Applying policies

Policies can be applied by using the "Edit policies" link in the sidebar, or by going to the ManagePermissionPolicies special page. Unfortunately, a search feature is not yet implemented. Therefore, to edit the policies of a particular object (the wiki, a namespace or a page), you must append the ID of the object to the special page's URL. The IDs have the following structure:

• wk - for the entire wiki
• ns-xxx - for a namespace; replace xxx with the ID of the namespace
• ns-special - for the Special namespace
• pg-xxx - for a page; replace xxx with the ID of the page
• sp-xxx - for a special page; replace xxx with the name of the special page

For example, to edit the permission policies of Special:Watchlist, you need to visit Special:ManagePermissionPolicies/sp-Watchlist.

Installation

• Download and place the file(s) in a directory called WikiGuard in your extensions/ folder.
• Add the following code at the bottom of your LocalSettings.php file:

  wfLoadExtension( 'WikiGuard' );
  

• Run the update script which will automatically create the necessary database tables that this extension needs.
• Done – Navigate to Special:Version on your wiki to verify that the extension is successfully installed.

See also

• Category:User rights extensions
• Lockdown - for managing permissions per-namespace.
• GroupManager (BlueSpice) - for adding, editing and deleting user groups.
• PermissionManager (BlueSpice) - for administering user rights to user groups.
• UserProtect - Allows per-user per-right per-page protection.
• PageOwnership - Multi-layered permission manager, whole wiki or specific pages, with friendly interface.
• AccessControl - Allows restricting access to specific pages and files.
• CategoryLockdown - Allows restricting access by category and group.