Extension:Simple Security
From MediaWiki.org
For further details, see Security issues with authorization extensions
 Release status: unstable |
|
|---|---|
| Implementation | Parser functions, User rights |
| Description | A simple to implement security extension |
| Author(s) | User:Nad |
| Version | 3.4.8 (2007-10-09) |
| MediaWiki | >1.6.0 |
| Download | SimpleSecurity.php |
This extension was design for MediaWiki 1.4.x and it is no longer practical trying to patch up bugs and holes. it is recommended to wait for version 4 which is being re-written for modern MediaWiki versions.
This is a simple solution involving a single snippet of code to be included from the LocalSettings.php file, it's been tested on version 1.6.7 and 1.9.3, and is being maintained at OrganicDesign:. It allows security directives to be placed in an article which affect the article's permissions, but are not rendered. The security directives are similar to how category links work in that they perform a function but do not render on the page. It's not very robust (see below for current flaws), and there's no encryption of data, but it's fine for general purpose use, and very easy to install.
[edit] Syntax & usage examples
- {{#security:actions|users/groups}}
Actions and users/groups are both comma-separated lists. Allowed actions are view, edit, history, move, delete, raw, watch/unwatch and protect. Users names start with an uppercase letter, group names are all lowercase. Assign users to groups using the usual Special:Userrights page. Following are a few examples:
- {{#security:*|admin,Fred}}
- {{#security:edit,delete|Sam,Fred}}
- {{#security:view,history|staff,consultants}}
Here's an example of using a pair of directives to allow everyone view-only access to an article
- {{#security:*|sysop}} {{#security:view|*}}
Notes:
- The syntax has changed in version 2.0 from square-brackets to curly-braces
- The * refers to any action and allows one to specify default permissions. The defaults will be overridden if another security link matches the action specifically.
- You can change the name used for security links with the $wgSecurityMagic global variable, by default it is "Security".
- In MediaWiki version 1.6.x, the magic words must include the hash (#) symbol explicitly if you want that syntax. In version 1.9.x the hash format is mandatory and implicit, and so must not be included in the global magic-names variables.
[edit] Groups & rights
The groups used in the security links refer to the usual MediaWiki groups managed in the Special:Userrights page. As of MediaWiki version 1.9.x group management only allows users to be added or removed from existing groups, but adding or removing the available groups needs to be done by changing either the LocalSettings.php or Security.php file/article. The $wgSecurityGroupsArticle global variable allows an article to be designated to hold a bullet list of additional group names for the available groups list in the userrights special page.
[edit] Denying anonymous access
Users who are logged in are automatically part of a group called user, so if you say {{#security:*|user}}, then all actions require the user to be logged in.
[edit] Inheriting article security from categories
Security settings can be assigned to articles in a category-wide way simply by adding the security link to the category article. Articles automatically inherit the security settings exhibited by any of the categories they're in. If an article also contains its own security links, they will override the inherited ones.
You can use an exclamation mark after the hash (a shebang) in a category page's security links to prevent them from being inherited by the contained articles, for example:
- {{#!Security:history|timelord}}
This will mean that you need to be in the timelord group to access the history of the category page, but access to the history of any of the articles in the category is unaffected.
Notes:
- The latest versions (and some older versions) of MediaWiki need the security info to be wikitext, other need it HTML. If the default setting is wrong for your setup, the $wgSecurityParseInfo global to true.
- You can enable/disable inhertited security with the $wgSecurityInheritable global variable
- You can change the name used for recursive security links with the $wgSecurityMagicNoi global variable, by default it is the same name as the normal security links but with a preceeding asterisk.
- Security inheritence is not recursive, i.e. any security that a category inherits will not be passed on to the articles it contains, only the security links it exhibits itself will be passed down (except those with preceeding asterisk as described above).
[edit] Security-based conditions
SimpleSecurity adds two parser-functions for rendering content conditionally based on security permissions or group membership. Here's a couple of examples,
{{#ifusercan:edit|Main page|Check the homepage editing [[todo list]]!|check the [[latest news]]!}}
This example renders a link to a todo list if the user has permission to edit the main page, otherwise a link to the news is rendered instead.
{{#ifgroup:sysop|Check the homepage editing [[todo list]]!|check the [[latest news]]!}}
Here's the same example again, but this time the conditions is whether or not the user belongs to the sysop group. A comma separated list of groups can be used for the group parameter in which case the condition will evaluate to true if the current user belongs to any of the groups in the list.
- Notes
- The last parameter is optional and defaults to an empty string if not supplied
- Extension:Tree view can be used with these options since it doesn't render nodes with no content
[edit] Security on images & files
If security links are placed into articles in the Image: namespace, the code can prevent the images or its thumbnails from being returned to the client if they don't have readable permission. This feature requires Apache's mod-rewrite to be running and have the following condition and rule (update to your own wiki's path if necessary).
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wiki/images/.+
RewriteRule ^/wiki/images/(.+) /wiki/index.php/Download/$1 [L]
This allows all requests into the images structure to be redirected to an article title which is intercepted by the security code and validated against security before the file is sent to the client. If the requested file is refused, then the file specified in the $wgSecurityDenyImage is returned in its place.
[edit] Security on Recent-changes and Watchlists
This extension doesn't directly support this feature, but another extension called Extension:TransformChanges will check if SimpleSecurity is installed and if so will filter any changes to non-readable articles from the list. Extension:TransformChanges is converts the rendered output format of Special:Recentchanges and Special:Watchlist from a list into a table for easy adjustment through CSS classes.
[edit] Installation
The code is a single snippet available from OrganicDesign:SimpleSecurity.php which you must should as a file of the same name in your extensions directory. You then include this from your LocalSettings.php file as follows:
include('extensions/SimpleSecurity.php');
If you're using MediaWiki 1.6.x but want the same hash syntax as normal parser functions, add the following lines after the include.
$wgSecurityMagic = '#security'; $wgSecurityMagicNoi = '#!security'; $wgSecurityMagicIf = '#ifusercan';
[edit] Global security settings
Here are some global variables which affect the operation of the extension. These should be set in your LocalSettings file after the include of the SimpleSecurity.php script.
| Variable | Default value | Meaning |
|---|---|---|
| $wgSecurityMagic | security | The parser-function name for security directives |
| $wgSecurityMagicNoi | !security | The name for non-inheriting security directives |
| $wgSecurityMagicIf | ifusercan | The name for doing permission-based conditional content |
| $wgSecurityMagicGroup | ifgroup | The name for doing group-based conditional content |
| $wgSecurityEnableInheritance | false | Specifies whether or not security directives in categories inherit to member articles |
| $wgSecuritySysops | array containing sysop | The list of groups whose members bypass all security (groups a all lowercase, user are ucfirst) |
| $wgSecurityDenyTemplate | Template:Action not permitted | The name of the article used when denying the user the ability to perform an action |
| $wgSecurityInfoTemplate | Template:Security info | The name of the article used to append security information to the page. |
| $wgSecurityEnableForImages | false | Specifies whether security directives in image/file articles also apply to the associated binary |
| $wgSecurityDenyImage | local mediawiki logo | The image returned in place of requested image if read access denied and using security on images. |
| $wgSecurityParseInfo | false | Whether or not the security info template needs to be wiki-parsed. Some older versions of MediaWiki will need this to be set to true or the security info sill display as raw wikitext instead of rendered HTML. |
| $wgSecurityGroupsArticle | empty | This can be set to the name of an article which contains a bullet list of additional groups for the available groups list in Special:userrights. |
| $wgSecurityRuleTemplate | empty | This can be set to the name of a template article to use for the action requires you to be a group message. |
[edit] Template examples
Here's an example of each of the templates which you can refine to your own needs:
[edit] Template:Action not permitted
<p style="font-size:125%;color:#c00;">'''Sorry, action not permitted!'''</p>
Your [[Special:Userrights|user rights]] do not permit the '''{{{1}}}''' action to be performed on the '''{{{2}}}''' article.
[edit] Template:Security info
{|width=100% style="border:1px solid #aaa"
|valign="middle">|<font size="20" color="#cc0000" face="serif"> '''!''' </font>
|align="left" valign="top" width="100%"|
<p style="font-size:110%;">'''There are [http://www.mediawiki.org/wiki/Extension:SimpleSecurity security] restrictions on this article'''</p>
{{{1}}}
|}
[edit] Dependencies
You'll need to install Apache's mod-rewrite for security on images and files to work. Also, the security.php code refers to a number of other articles. The article names and their purpose are listed below, and they link to the Organic Design wiki where they're maintained.
[edit] Testing
This extension has been tested in the following environments:
- works with PHP 4.x and PHP 5.x
- works with MediaWiki 1.6.7
- works with MediaWiki 1.9.3 - more bugs found and fixed 04:28, 20 April 2007 (UTC)
[edit] Bugs & Todo
- Change users/groups handling to not rely on case of first letter
- Still failing on diffs under certain circumstances --Nad 10:30, 1 May 2007 (UTC)
- Page is empty except for the "access denied" message when viewing diff's for articles you're not allowed to see
- Many of the same directives should only be displayed once
- Subsequent inherited items should overwrite (care needs to be taken with cat order)
- Users shouldn't be able to set security that prevents them from accessing it themselves
[edit] Security holes
There is a list of flaws often found in MediaWiki security extensions here, and I've included the ones that this extension currently suffers from below. There is a solution to these issues in progress.
- diff: Under some circumstances article content is being shown in diffs when it shouldn't be.
- Search article: Do you get results with partially displayed text?
See also bugzilla:8825 - Atom/RSS feeds: Does the article get delivered? There are two feeds, one in the Recent changes special pages and other on the page history.
For extensions using the userCan hook, this has been fixed in MW 1.10, rev:19944. - XML export (Special:Export): Is it possible to export the contents of a protected page?
For extensions using the userCan hook, this has been fixed in MW 1.10, rev:19935. - Transclusion: You can view private articles by transcluding them. This was fixed in older versions of MediaWiki, but has at some stage become a problem again. This should be fixed again soon.
[edit] New solution in progress to fix remaining security flaws
Fixing the remaining flaws of search, XML-exports and diff's containing information which should be inaccessible is quite a problem because those functions are obtaining article content with their own SQL queries, rather than fetching the content via the $wgArticle object. XmlWiki overcomes the problems by intercepting and filtering the rendered content, but that method is a hack and doesn't protect against other extensions which render differently structured content.
What's really needed is a way to intercept the database rows as they're retrieved for rendering, but there are no official hooks in that level of the MediaWiki code (not in version 1.6.x anyway). But I've found a method of dynamically adding a new hook to the DatabaseXXX::fetchObject() method which is the method called by search, XML-export and RSS-feeds (and probably anything else which plans on iterating through the results of an SQL query).
This hook has been created and tested on MediaWiki 1.6.8 and is called DatabaseFetchObject which is a separate extension. It will be used by the SimpleSecurity.php code if the hook is installed, or will just work as usual if the hook is not present.
[edit] Change Log
[edit] Version 3.4.8 (2007-10-09)
- Added a new hook called "IsAllowed" which is called from the $wgUser's isAllowed method. The hook is currently unused but will be used in future versions to work more in line with MediaWiki's rights and permissions.
[edit] Version 3.4.6 (2007-07-19)
- Fixed bug which prevented group "user" from working (use getEffectiveGroups methods instead of getGroups)
[edit] Version 3.4.5 (2007-07-17)
- Added #ifgroup parser function
[edit] Version 3.4.4 (2007-05-19)
- Fixed a bug causing the global $wgGroupPermissions operations to be ignored.
[edit] Version 3.4.1 (2007-05-01)
- Fixed deny-template wikitext showing up.
[edit] Version 3.4.0 (2007-05-01)
- Added the $wgSecurityGroupsArticle global for adding extra available groups for the userrights special page.
[edit] Version 3.3.1 (2007-04-21)
- Added the $wgSecurityParseInfo global to cater for older versions of MediaWiki not parsing the security info message.
[edit] Version 3.3 (2007-04-20)
- Security was failing to work for diff's which is fixed, but clears the page for some reason
- Security was failing for view action under various circumstances on 1.9.x which has been fixed
- Security info was rendering in weird places which has been fixed by using a different hook
[edit] Version 3.2
- Global $action set to "raw" if request is an intercepted file/image so processing not wasted rendering page which isn't used
[edit] Version 3.1
- The file/image security had to be re-implemented to work with the version 3.0 and is working again now.
- Two additional gloals were added to enable/disable file-based security, and to specify a file to return if the requested one is denied.
- Checks if encoding type is gzip and gzips before sending for file security
[edit] Version 3.0
- The whole thing has been rewritten based on the parser functions extension so that it works in accord with the MediaWiki object-oriented convensions and works across the MediaWiki versions better.
- It now installs in the same way as other extensions.
- The #ifusercan function was added for allowing rendered content to be dependent on permissions
[edit] Version 2.0
The major difference in this version 2.0 is that the newer version has changed the syntax of the security links from square brackets to braces. The problem with the brackets method is that it required the code to extract and remove the security information from the article using a pattern match and replace on the text, which is very inefficient. Using braces allows a tighter integration with the MediaWiki parser so that the parser itself calls a function to process the security directives as it comes across them.
The second difference is that the security validation is done on the ArticleAfterFetchContent hook so that the security is assessed for transcluded articles as well as the main title article. I thought this would also fix the security holes listed above, but those still need a little more work!
