Difference between revisions of "IntraACL"

Revision as of 16:24, 23 October 2013

IntraACL is a MediaWiki extension.

• Main purpose: Best page-specific rights extension for MediaWiki. It is based on HaloACL, correcting its endless bugs and inconveniences.
• Repository: https://github.com/mediawiki4intranet/IntraACL
• Homepage: http://wiki.4intra.net/IntraACL 
• Compatible MediaWiki versions: guaranteed 1.19-1.25, maybe others 
• Authors: Vitaliy Filippov & Stas Fomin. Based on HaloACL by ontoprise GmbH, 2009.
• License: GPLv3.0+ 
• Created: 2010-09-03 
• Last version: 2.1.8 
• Our rating: Definitely useful (5)

Status for Mediawiki4Intranet distribution:

• Inclusion date: 2010-09-03
• Included version: newest available
• Improvement status: Created by MediaWiki4Intranet project

Introduction

Page-specific rights in MediaWiki

MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content. But with the massive increase of MediaWiki use in corporate intranets and the many CMS-like features emerging, demand for tighter security is emerging.

As you know, MediaWiki was designed as Wikipedia engine. Wikipedia is open and doesn't need access rights. Moreover, one of WikiWiki principles is to allow easy and fast editing for anyone, and of course, access must also be open.

This is why MediaWiki is not designed to protect anything from anyone, except from anonymous editing. There is plenty of ways to break the read rights (page inclusion, recent changes and etc), especially when any of 1700+ MediaWiki extensions can use direct database access (if it couldn't, MediaWiki would probably be as fast as all other "global and stable Ntrprise").

Examples of such ways are described here: Security issues with authorization extensions and here: page with comparison of existing access control extensions, from which we did know about HaloACL.

Original HaloACL already solves most of these problems, but when we tried to use it, we discovered many bugs, inconveniences, and slow interfaces (thanks YAHOO UI library). So we started to improve it, and then forked it and called IntraACL.

IntraACL features

• Interactive right editor (special page).
• Ability to create pages protected from beginning.
• Page protection.
• Category protection.
• Namespace protection.
• Right inclusions.
• Right definition using Wiki pages inside a special namespace.
• User groups, group-into-group inclusions - orthogonal to MediaWiki groups, also stored on wiki pages.
• Easy protection of content used on a page.

Requirements

In theory IntraACL should work for any MediaWiki >= 1.14. But in fact, patches are available for at least 1.18.

Installation

First checkout IntraACL code to extensions/IntraACL.

There is a new version available in 'storage-rewrite' git branch which should deliver better performance, but it is in beta state by now. It passes right evaluation tests and it should have no critical bugs, so you can already use it.

Then add the following lines into your LocalSettings.php:

require_once('extensions/IntraACL/includes/HACL_Initialize.php');
enableIntraACL();

You can also add custom configuration options before enableIntraACL() call. For the option list, see extensions/IntraACL/includes/HACL_Initialize.php or this page.

Then apply patch for appropriate version of MediaWiki:

cd YOUR_WIKI_INSTALLATION_DIR
patch -p0 < extensions/IntraACL/patches/IntraACL-MediaWiki-<YOUR_VERSION>.diff

Run MediaWiki database update tool:

php maintenance/update.php

You should check all your extensions for compatibility with IntraACL because of possible security breaches.

The method of IntraACL installation via the super-duper-installer of Halo MediaWiki bundle is now removed as very non-standard.

Configuration

# Set this variable to false to disable the patch that checks all titles
# for accessibility. Unfortunately, the Title-object does not check if an article
# can be accessed. A patch adds this functionality and checks every title that is
# created. If a title can not be accessed, a replacement title called "Permission
# denied" is returned. This is the best and securest way of protecting an article,
# however, it slows down things a bit.
$haclgEnableTitleCheck = false;
 
# This variable controls the behaviour of unreadable articles included into other
# articles. When it is a non-empty string, it is treated as the name of a message
# inside MediaWiki: namespace (i.e. localisation message). When it is set to an
# empty string, nothing is displayed in place of protected inclusion. When it is
# set to boolean FALSE, inclusion directive is shown instead of article content.
$haclgInclusionDeniedMessage = 'haloacl-inclusion-denied';
 
# This flag applies to articles that have or inherit no security descriptor.
#
# true
#    If this value is <true>, all articles that have no security descriptor are
#    fully accessible for IntraACL. Other extensions or $wgGroupPermissions can
#    still prohibit access.
#    Remember that security descriptor are also inherited via categories or
#    namespaces.
# false
#    If it is <false>, no access is granted at all. Only the latest author of an
#    article can create a security descriptor.
$haclgOpenWikiAccess = true;
 
# Values of this array are treated as language-dependent names of namespaces which
# can not be protected by IntraACL.
$haclgUnprotectableNamespaces = array();
 
# If this is true, "ACL" tab will be hidden for unprotected pages.
$haclgDisableACLTab = false;
 
# If $haclgEvaluatorLog is <true>, you can specify the URL-parameter "hacllog=true".
# In this case IntraACL echos the reason why actions are permitted or prohibited.
$haclgEvaluatorLog = true;
 
# If you already have custom namespaces on your site, insert
#    $haclgNamespaceIndex = ???;
# into your LocalSettings.php *before* including this file. The number ??? must
# be the smallest even namespace number that is not in use yet. However, it
# must not be smaller than 100.
$haclgNamespaceIndex = 102;
 
# This specifies how different right definitions which apply to one page combine.
# There may be page, category and namespace rights.
# Possible values:
# - HACL_COMBINE_EXTEND: user has the right if it is granted within ANY of the applicable definitions.
# - HACL_COMBINE_SHRINK: user has the right only if it is granted within ALL applicable definitions.
# - HACL_COMBINE_OVERRIDE: more specific rights override less specific ones.
#   I.e. page rights override category rights, which override namespace rights.
$haclgCombineMode = HACL_COMBINE_EXTEND;
 
# Names of MediaWiki groups members of which are IntraACL super-users
# and can view and edit all articles, ACLs and etc. It is needed to
# have someone who can repair incorrect right definitions created by users
# (which is a very common scenario in the case of IntraACL because of a
# relatively complex right model).
$haclgSuperGroups = array('bureaucrat', 'sysop');
 
# Preload 1000 SDs individually granted for current user during right checks.
# If your database is very large and this number is exceeded, IntraACL will begin to
# make individual DB queries for the access check of each separate page.
$iaclPreloadLimit = 1000;
</pre>
 
== MediaWiki 4 Intranet ==
 
You can also use Mediawiki4Intranet bundle. It already includes IntraACL and many other useful extensions which are made compatible with it.
 
See [[Mediawiki4Intranet]].
 
== Patches ==
 
Patches are available for 1.18.6, 1.19.8, 1.20.7, and 1.21.2 in the repository under /patches.