Why a Wiki for yourself?
- For myself!
- At home or not, I can use any computer with an internet connection to read and/or write pages containing knowledge I have collected. A Wiki gives any user the possibility to access and share information anywhere in the world with anybody.
- I am using 2 wiki's at this moment,
- An Intranet version at home on my MacBookPro as an extension for my mind.
- An Internet version at One.com for sharing Information with others.
- Sharing information with people I like!
- Meaning not everybody can share his ideas here. To share information you need my permission to edit/change pages. if you want to reach me, you can use email.
- I am convinced wikis, especially WikiPedia, have an added value to humanity.
Initially the Talk-pages have been open to add/edit/submit action by all users. Unfortunately I am forced to close these actions for not-registered users due to abuse by misbehaving users. Sorry, but they leave me no other choice!
Portal and Security
Everyone can help to build My-Harm-Wiki into a better site by editing the existing articles. The information of this wiki is partly public shared, partly shared to a selected group and partly strictly personal. These facts make it impossible to grant access to anybody. Also not everybody who has read-access to articles is also allowed to edit these pages or even to create new pages. So I need a Security Model for my wikis!
MediaWiki does not support or have a Security Model and also MediaWiki is not written to support a Security Model . For my old Wiki-Site I had written a Lean-and-Mean Access Control mechanism and although MediaWiki does not encourage writing such an model I decided to create one based on the Role Based Access Control Model (RBAC Model). The model extents 2 MediaWiki Hooks:
- MediaWikiPerformAction is made responsible for checking the user-rights for normal pages. Based on the existing UserGroups and Categories and new created UserGroup-Categories relation. See RBAC for Categories for details.
- BeforeInitialize is made responsible for checking the user-rights for special pages. Based on the existing UserGroups and new created UserGroup-Special-Pages relation. See RBAC for Special Pages for details.
RBAC for Categories
The RBAC model works as follows. The first 2 most important implementations for the model is:
- Every User has at least one Role.
- Every wiki-Article belongs to at least one Category.
Look at the bottom of this page. You see that this page belongs to the Category Index. This relation has to be made when the pages is created. It is always possible to change this page-category relation.
The relation between User and Role (which is named UserGroup in this wiki) is created and maintained by the wiki-administrator and is hidden for the user.
Now the Roles (or UserGroups) has to have a relation to the Categories. But this relation needs an extra attribute the so-called access-privilege. This access privilege is based on the database access as described by the Create CRUD matrix (Create, Read, Update and Delete). This structure has been created using extsing and new functionali ty in the MediaWiki database.
|The field abbreviations for the column type are:
||u2g_right is an enum. The values are stored in the table CrudRights' and have the values:
The tables User, Usergroup, CategoryLinks and Page are in the basic MediaWiki implementation. The tables Ug2Cat and CrudRight are new.
The presented RBAC Schema is very abstract and it may be difficult to be used without giving an example. Therefor all database-tables are shown below and their changes for usage of the RBAC model. In this example the imaginary Usergroup HAL and Category WorkSpace are introduced .
The table User is not altered. Every new user can be added, deleted, changed as usual.
The structure of the UserGroup table is not altered. Only the content has to be changed (by changing the LocalSetting.php file).
To make optimal usage of the power of the MediaWiki Groups and the RBAC implementation it is necessary to limit the normal usage of the users.
Therefor it is needed to alter/add the settings of the wgGroupPermissions in LocalSettings.php.
- In a standard MediaWiki implementation the wgGroupPermission is not present, so you'll need to add these statements.
- In this example-implementation a user can not create an account. Only the sysop can.
/* ** Implicit group for all visitors */ $wgGroupPermissions['*' ]['createaccount'] = false; $wgGroupPermissions['*' ]['createpage' ] = false; $wgGroupPermissions['*' ]['createtalk' ] = false; $wgGroupPermissions['*' ]['read' ] = true; $wgGroupPermissions['*' ]['edit' ] = false; $wgGroupPermissions['*' ]['writeapi' ] = false; /* ** Implicit group for all logged-in accounts */ $wgGroupPermissions['user' ]['move'] = false; $wgGroupPermissions['user' ]['read'] = true; $wgGroupPermissions['user' ]['edit'] = false; $wgGroupPermissions['user' ]['upload'] = false; /* ** Makes every User a member of the bot group */ $wgGroupPermissions['bot' ]['bot'] = true; $wgGroupPermissions['bot' ]['edit'] = true; $wgGroupPermissions['bot' ]['createpage'] = true; $wgGroupPermissions['bot' ]['createtalk'] = true;
If you make every new-user member of the bot-group, he/she can do basic editing. The next step is to create a new usergroup with explicit rights to be used in combination with the attached category (See later). In the examples here presented this usergroup is called 'HAL'. See for details of Usergroups:
- User Rights on Mediawiki descpription for the LocalSettings.php.
The $wgGroupPermissions is an associative array, controlling permissions for creating and editing pages for your different user groups. In this array, custom permission levels can be created, and permission levels for the different user groups can be set.
- Help User Rights description on Mediawiki.
UserGroup to Category
|Table Ug2Cat Description|
|This table is the key for the RBAC implementation. It is used for implementation of the functions:
|UserGroup has access to all Categories||Auto||sysop||0||15||Sysop has all CRUD-access (15) to all Categories (0)|
|UserGroup has access to 1 Category||Auto||hal||26||15||HAL has all CRUD-access (15) to Category WorkSpace (26)|
|Every UserGroup has access to 1 Category||Auto||*||9||2||Everyone (*) has CRUD-read-access (2) to Category Help (9)|
A typical implementation of the ug_cat:
INSERT into `ug2cat` (`u2g_ug`, `u2g_cat`, `u2g_right`, `u2g_description`) VALUES ( 'sysop' , 0, 15, "Sysop has all-access to all categories"), ( 'hal' , (Select `cat_id` FROM `category` WHERE LOWER(`cat_title`) = 'workspace' ), 15, "All-Access-Rights to category WorkSpace"), ( '*' , (Select `cat_id` FROM `category` WHERE LOWER(`cat_title`) = 'help' ), 2, "Everyone has Read (view) Access-Rights to category Help");
The tables is not altered. The content is changed by adding a category to every wiki page.
The table is not altered. The content is maintained by the normal wiki handling.
RBAC for Special Pages
MediaWiki adds many Special Pages. Nice for adding extra information, but also a security-issue when such an extension or extra page does not follow the architectural design of MediaWiki. The default access for Special Pages is forbidden, the u2g_spec script for creating entries gives the basic security for MediaWiki, not for all other extensions.
The table User is not altered. Every new user can be added, deleted, changed as usual.
The table UserGroup is not altered. See for additional information UserGroup.
UserGroup to Special Page
|Table Ug2Spec Description|
|This table is the key for the RBAC implementation for the special pages. It is used for implementation of the functions:
|UserGroup has access to all Special Pages||Auto||sysop||*||15||NS_SPECIAL||Sysop has all CRUD-access (15) to all SPs|
|UserGroup has access to 1 Special Page||Auto||hal||Contributions||15||NS_SPECIAL||HAL has all CRUD-access (15) to SP-Contributions|
|Every UserGroup has access to 1 Special Page||Auto||*||Userlogin||2||NS_SPECIAL||Everyone (*) has Read-access (2) to SP-Userlogin.|
The installation of WikiRBAC does not require additional changes to the MediaWiki code except for the file LocalSettings.php.
- Adding of the additional files for WikiRBAC by adding
- Adding of the wgGroupPermissions as described above.
The installation requires the addition of 2 extra tables to the MediaWiki Database.
The SQL-statements to create the 2 tables are provided in the installation (RBAC_CRUD.sql).
The WikiRBAC uses the MediaWiki Hooks to add the RBAC-Functionality to MediaWiki. The 2-hooks used are:
- 'MediaWikiPerformAction' which is used for accessing of normal pages using the the UserGroup to Categories RBAC Model
- 'BeforeInitialize', which is used for accessing the Special Pages using the UserGroup to Special Pages RBAC Model.
The WikiRBAC consists on the files:
- Util.php, Utility class for logging, and static implemenations
- WikiRBAC.php, main entry point for both hooks
- WikiRBAC.Hooks.php, Currently not used, but basics for testing
- WikiRBAC.i18n.php, Language specific texts used in the extension. Currently only English and Dutch support.
- WikiRBAC.i18n.magic.php, Magic functions
and there are changes made to:
As earlier stated MediaWiki is not a Content Management Systems (CMS) . The following issues have to be addressed to secure your website.
There are two feeds:
- Recent changes special pages
- New pages
- Optional additional feeds provided by extensions.
The problem of the feeds are that the additional check for access is not made (MediaWikiPerformAction). There are 2 options, both not optimal to cover this problem:
- Disable the Special Pages 'NewPages' and 'RecentChanges' for Read-Access to all users.
- Disable the Atom/RSS feed generation to all users. In the LocalSetting add the lines:
$wgFeed = false; $wgFeedClasses = array();
It should be nice as a MediaWiki Hook is added into the Atom/RSS feed generation.
- DbTrace for MediaWiki, A private tool for MediaWiki monitoring users and page views. Statistic information of Wiki-Visitors and Wiki-Page-Views
- RBAC, Role Based Access Control description and examples.