Extension talk:PageSecurity

Feedback about version 1.1.4

Some feedback on this plugin. I just installed it on MediaWiki 1.9.3, running on Windows Server 2003. No problems at all. This is exactly what we needed. Just one remark, we are using an old version of MySql: 4.0.20a-nt, and I had some troubles executing the SQL you proposed. I had to delete "DEFAULT CHARSET=latin1;" for both statements. And for the second statement I had to delete USING BTREE.
So these are the SQL statements that worked fine for me:

CREATE TABLE `security_definitions` (
  `security_definition_id` int(10) unsigned NOT NULL auto_increment,
  `security_definition_name` varchar(255) NOT NULL,
  `base_security_definition_id` int(10) unsigned NOT NULL,
  `security_definition_notice` varchar(255) NOT NULL,
  `security_definition_logo` varchar(255),
  PRIMARY KEY  (`security_definition_id`),
  UNIQUE KEY `Name` (`security_definition_name`)
) ENGINE=InnoDB;

CREATE TABLE `security_definition_items` (
  `security_definition_item_id` int(10) unsigned NOT NULL auto_increment,
  `security_definition_id` int(10) unsigned NOT NULL,
  `security_definition_item_action` varchar(255) NOT NULL,
  `security_definition_item_permission` char(5) NOT NULL,
  `security_definition_item_group` varchar(255) NOT NULL,
  PRIMARY KEY  (`security_definition_item_id`),
  KEY `security_definition`  (`security_definition_id`)
) ENGINE=InnoDB;

I just wanted to share this. Maybe this is useful for others as well.
85.91.175.214 18:02, 12 April 2007 (UTC)

Questions

Page creation protection

Q: I have come across an issue when a set of pages are write protected by title and the page doesn’t exist – the checks allow the creation but not the subsequent editing. The following patch appears to work but I am not sure it is the correct fix.

--- PageSecurity.php.orig       2007-05-12 09:08:45.000000000 +0100
+++ PageSecurity.php    2007-05-12 09:09:12.000000000 +0100
@@ -195,7 +195,7 @@
     private static function doUserCan($title, $user, $action) {
        // get page data
        $content = SecurityManager::getRevisionText($title);
-       if (empty($content)) return true;  // nothing to check
+       if (empty($content)) { $content = ""; }
 
        // check permissions
        if (empty(SecurityManager::$securityDefinitions[$title->getPrefixedDBkey()])) {

The problem with the patch is that it it simply displays the 'protectedpagetext' message. I ended up having to edit that message and trans-include the access restricted page so that I full explanation is always presented. --SteveBleazard 09:37, 12 May 2007 (UTC)

Actually with further thought the use of the protectedpagetext makes it easier to build alternative links into the error page that use the original page name so using the protectedpagetext message is actually a good thing --SteveBleazard 15:11, 12 May 2007 (UTC)

Discussion Page

Q: Hi Fernando, When you protect a page against writing, the associated discussion page is also blocked for writing. Is it a bug or a feature? How to work around? Cheer, --81.56.156.23 16:51, 1 March 2007 (UTC)

A: This is a restriction. There is some information about how to circumvent it is here. If you try this solution and find out more please provide some feedback. I think the PageSecurity extension could be enhanced to support this feature. --Fernando Correia 17:02, 1 March 2007 (UTC)

I tried to install the talkright extension in conjunction with PageSecurity. User Talk page is still locked. PageSecurity protection seems to be stronger than Talkright protection. I expect something like

<allow action="talk" ... 

to be added in security definitions. BTW, I can help with translation to French for messages. --Antoine Sirianni 07:36, 2 March 2007 (UTC)

I guess you're right. Now PageSecurity only has "read" and "write" permissions. We could add a "talk" permission. If you know some programming and are willing to try it, feel free. I will add this to the requested features list, but currently this is not a priority for me. If you do some translation please post it back and I will integrate it on the source code. Thanks! --Fernando Correia 12:02, 2 March 2007 (UTC)

Protect some pages and others public

Q: Is it possible to let pages public and to hide others?

A: Yes. The PageSecurity extension enhances, but does not replace, the native MediaWiki access control. You can create a protection expression that protects a single page on your wiki, for instance by its title, or that protects a namespace. The PageSecurity extension will apply the security definition to that page or namespace, and the default MediWiki rules will apply to all the other pages. Another approach is to define a default security definition that should be applied to all pages that are not covered by a protection expression. --Fernando Correia 21:02, 26 February 2007 (UTC)

Protecting uploaded files

Q: Does this extension work for uploaded files as well? While adding a Security Template to the comment might protect the file's summary page, a direct download would probably still be possible - so anyone who can see the file list (Special:Imagelist) could get to any file, no matter whether its description page is protected or not!? FND 06:52, 14 February 2007 (UTC)

A: No, it protects only normal pages, not uploaded files and images. Currently it is out of the scope of this extension. And as you pointed out, even though we could patch MediaWiki to apply security definitions for uploaded files, they are published by the web server independently of MediaWiki and so are out of control of extensions. --Fernando Correia 15:33, 14 February 2007 (UTC)

That's a problem, of course... So my best bet would be to block acces to Special:Imagelist (if that's even possible) so the URLs are not revealed there? (Protecting the file's description page should work with PageSecurity, and pages linking to protected files should usually be protected as well, so there'd no way to get to the file's URL - except for URL guessing, of course.)

-- FND 17:33, 14 February 2007 (UTC)

Thanks for your feedback. I'll write it down as a feature request. It's not a priority for me now, though. --Fernando Correia 18:16, 14 February 2007 (UTC)

There recently was a similar discussion on the mailing list; could this maybe solve my/our problem here?

-- FND 17:08, 27 February 2007 (UTC)

I think so. I was not aware of this feature before this post on the mailing list. Since there already is a standard way to handle this, this feature may not be needed on the PageSecurity extension. I don't have enough information about this now, though. --Fernando Correia 17:17, 27 February 2007 (UTC)

I've tried including the some sorta PageSecurity check in the img_auth.php - unfortunately, no luck so far (which might be due to the fact that I have no clue what I'm doing... ).

Can you maybe give me a hint?

-- FND 09:05, 5 March 2007 (UTC)

I'm not familiar with img_auth.php, but if you want to check read rights using PageSecurity, I think the easiest way is to simulate a "userCan" hook call. That means calling fnPageSecurityUserCanHook(). You should pass "Image:filename" as the title, removing the path name from the filename. You also need to have an $user object. That should have the same effect of MediaWiki trying to access the image page. --Fernando Correia 12:12, 5 March 2007 (UTC)

Unfortunately, I have no idea what that means or even how to do it. (Sorry for being such a leech here... )

I thought there was one central function handling the permission stuff, but it seems it's not quite as easy as I'd hoped.

-- FND 15:17, 5 March 2007 (UTC)

The central function is fnPageSecurityUserCanHook(). It will return true if the user can access the page. --Fernando Correia 16:48, 5 March 2007 (UTC)

I've added the following to lines 45ff of img_auth.php (MW v1.9.2):

# PageSecurity check
$thisFile = basename($filename);
if( !fnPageSecurityUserCanHook($thisFile, $wgUser) ) {
	wfForbidden();
}

However, that doesn't seem to have any effect whatsoever - it even makes no difference when I remove the exlamation mark.

Also, I'm not sure what to with the fnPageSecurityUserCanHook function's arguments $action and $result.

Again, my apologies for being such a dimwit here...

-- FND 09:06, 6 March 2007 (UTC)

Error on saving

Q: I'm trying to install the PageSecurity extension, and apparently it seems that the table (prefix_)security_definitions does not get created in the first place. I've patched the files in the installation instruction, and followed every steps. What could be wrong? --162.129.251.29 02:16, 28 April 2007 (UTC)

Q: I am getting a strange error when I go to save a page.

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
   (SQL query hidden)
from within function "SecurityDefinition::loadFromDatabase". MySQL returned error "1054: Unknown column 'security_definition_logo'  in 'field list' (localhost)".

A: Your database is missing the 'security_definition_logo' field. Please follow update instructions. --Fernando Correia 00:07, 14 February 2007 (UTC)

EDIT: Works after I added the logo field (doh). Now it just seems to not work. I am making xml tags for rules and the database never seems to update. Also, the page doesn't retain the test I type. I am adding somthing like this:

<security-definition name="Free access" base="Default"
 notice="This page can be read and written by all except guests.">
 <allow action="write">all</allow>
 <deny action="write">Guests</deny>
</security-definition>

I can save the page but nothing shows up on the page and the database isn't updated. No errors either.

Thanks, Anyone know why? 192.18.128.5

A: Do you receive a blank page? This might indicate some processing error. The best option in this case is to turn on debug information to see the error message. Please provide more details about this behavior. --Fernando Correia 00:07, 14 February 2007 (UTC)

Defining Security Options directly in a page

Q: From what I understand (the description is a little convoluted), the current process for securing pages looks like this (after completing the installation process):

1. create user groups by adding something like the following to LocalSettings.php ("..." is a placeholder for the group's name):

   $wgGroupPermissions['...']['read'] = true; $wgGroupPermissions['...']['edit'] = false;

2. assign users to Groups via Special:Userrights
3. create a wiki page containing a list of security definitions (as described here), which are basically protection templates
4. assign security definitions to pages by creating an entry in LocalSettings.php for each definition (as described here)

That means that securing a page is quite an elaborate and tedious process, as the wiki admin needs to make changes to LocalSettings.php.

Isn't there a way to add access permissions directly to a page, e.g. by adding something like the following to the page content:

<PageSecurity allowRead="Employees, Contractors, Guests" allowEdit="Employees, Contractors"/>

(This might be more of a suggestion than a question, so feel free to move this whole section.)

I'd appreciate some comment on whether this is (or will be) possible! -- FND 12:28, 13 February 2007 (UTC)

A: Thank you for your feedback. You understood the process correctly. About your perception, I can comment that securing a wiki (not page) is an elaborate process. It is not necessarily tedious, I think that would depend from personal inclinations and motivations. I don't think it is more elaborate or tedious than establishing security definitions for an intranet or a more conventional CMS system. About the suggestion to apply security specifically to a single page, that could be possible but right now I don't think it would add much value. If there is a page that needs special protection you can do this by creating a security definition and a rule specifically for its title. The PageSecurity extension is designed by the principle that in most cases it is desired to apply the same rule to a large set of present and future pages. This is achieved by making the pages have some common characteristics like namespace, part of title or an included template. Since the rules are not in the pages, only the administrator can see and change them. And since they are centralized, maintenance cost will be lower and security will be better because a single change in a single place will change the rules to the whole set of pages, and it is possible to see all the rules in a single place. This is similar to the way Windows allows us to specify user group rights to directories of files. That said, I'd welcome a patch to extend it to allow definition page-by-page, provided such patch is coherent with the overal design of the extension. --Fernando Correia 13:21, 13 February 2007 (UTC)

Thanks for the quick response, Fernando! I have now fully set up the PageSecurity extension (it was a bit confusing for me, so it took me a bit to get it right), so I can do some actual testing. I guess I'll just use a couple of templates (as described here) so users don't always have to ask the admin for basic changes.

Either way, great extension; I'm sure it took (and takes) a lot of effort to develop (and maintain)! FND 13:44, 13 February 2007 (UTC)

You're welcome. Please feel free to post here other questions and feedback. --Fernando Correia 15:40, 13 February 2007 (UTC)

How do you make it use the definitions

Q: I have applied all the patches, and created the definitions and groups. It is not clear to me HOW the extension reads the definitions page or information. The instruction say put them on one page or many pages, but which page? Does the XML go onto the page you want to protect? Can you hide the output of the security definitions?

I set a $wgPageSecurity to match but it seems to ignore it.

Logo image issues

A: It seems like a problem with a version upgrade. The database of version 1.0.0 did not have the field 'security_definition_logo'. This field is used by the source code of version 1.1.0 and up. I advise you to follow the upgrade instructions at Extension:PageSecurity/Upgrade_instructions and to make sure you have the latest version of the database table and of the source code. --Fernando Correia 18:01, 13 February 2007 (UTC)

Q: How can I use relative paths with the LOGO attribute (something like logo="skins/common/images/logo.png" didn't work)? Also, how can uploaded images be used for this? FND 13:35, 13 February 2007 (UTC)

A: You should specify the full URL of the image. To see the URL of an uploaded image, click on it and then click again on the link with the image file name. The browser should now be showing only the image, and on the address bar will be the image's URL. --Fernando Correia 15:40, 13 February 2007 (UTC)

Security definitions failed

Q: After going through the whole process of installing this extension, I got to the point where you have to create the security definitions page. That I did, but after inserting the sample XML from the description and saving the page, it comes back as empty! Curiously though, the preview displays the list correctly. (I'm running MW v1.9.2, maybe that's the problem!?) -- FND 15:15, 12 February 2007 (UTC)

A: Never mind, found the problem: After removing the following section, it shows up as it should:

<security-definition name="Free access" base="Default"
notice="This page can be read and written by all except guests.">
<allow action="write">all</allow>
<deny action="write">Guests</deny>
</security-definition>

-- FND 15:21, 12 February 2007 (UTC)

I'm not sure about what went wrong. But I will take a look at it. --Fernando Correia 17:06, 12 February 2007 (UTC)

I had the same problem, though I cannot figure out exactly what I did to fix it. I would recommend against copying and pasting from the instructions page. Rather, type it all up. Maybe there's a hidden character it is choking on in the explanation?

Patch utility

Q: What is the patch utility, and where can I find it?

A: It is a UNIX utility. People familiar with developing on Unix like to use it. See w:en:Patch_(Unix) and http://www.gnu.org/software/patch/patch.html. People familiar with Windows might prefer WinMerge. --Fernando Correia 17:06, 12 February 2007 (UTC)

Special pages

Q: Can I apply security-definitions to special pages (i.e. all special pages or just a particular one)?

A: No, this extension only protects regular pages. MediaWiki has a feature that restricts access to special pages. There is some information about this on Preventing Access. The source file SpecialPage.php provides hints on how to do this. --Fernando Correia 16:31, 23 January 2007 (UTC)

Page history

Q: How can I restrict access only to all history pages?

A: No, the extension currently can't restrict access only to the "history" page. If the user has read access to the page he will have read access to previous versions as well. --Fernando Correia 19:00, 22 January 2007 (UTC)

MediaWiki 1.9

Q: Does the extension work on version 1.9.0?

A: It has been released for MediaWiki 1.9.1 as version 1.1.1. See the upgrade instructions. --Fernando Correia 12:33, 29 January 2007 (UTC)

Follow-up Q: I assume it will still work with MW v1.9.2? Also, the MonoBook section says it's for 1.8.2, but I assume nothing has changed there in 1.9.x!? -- FND 13:52, 12 February 2007 (UTC)

A: As of version 1.1.1, the extension will work with any MediaWiki 1.8 or 1.9. But the patches provided are for MediaWiki 1.9.1. For version 1.9.2 the patches must not be downloaded, the must be applied manually to the right places of the version 1.9.2 files. Otherwise you could replace the new file with an older one. I hope I can provide patches for 1.9.2 soon. About the reference to 1.8.2, they were wrong and I removed them. Thanks. --Fernando Correia 17:06, 12 February 2007 (UTC)

Thanks for the quick response(s), Fernando! I downloaded the full source code of each file and replaced the original files, so I should be good. -- FND 19:10, 12 February 2007 (UTC)

It seems that you replaced files of version 1.9.1 over files of version 1.9.2. This may lead to problems. The procedure would be to manually insert only the patched sections into the files from version 1.9.2. Anyway I hope to be able to release this soon. --Fernando Correia 19:40, 12 February 2007 (UTC)

Wich PageSecurity version is compatible with MediaWiki 1.6.10

Q: I use the Modified source code by Jonabbey (version 0.7, 16 May 2006
with MediaWiki: 1.6.10 / PHP: 4.4.4 (apache) / MySQL: 4.0.23-standard

Now I get the error message:

 function.implode: Bad arguments in includes/Parser.php on line 337

If this is caused by an ill-fitting combination of code-versions:
Which PageProtection version is the correct one (and where to be found)?
Or is something else wrong?--Jeroen Koning 06:23, 24 April 2007 (UTC)

Does the extension work on version 1.9.3

Q: Does the extension work on version 1.9.3? I've followed all of the instructions and installed the patches, but can't get this working. Does it work with 1.9.3? I'm not seeing the security definitions applied to the page meta tags.

A: Yes, my production environment is 1.9.3. The extension setup is somewhat convoluted; I suggest double-checking the installation and configuration instructions. Make sure the extension is activated (in your Version special page), that you have saved the page with the security definitions, and that you have created valid protection expressions. For a simple test you could define a default security definition. It should appear on the page meta tags when you view the HTML source code of the generated pages. --Fernando Correia 19:35, 5 March 2007 (UTC)

Anonymous users

Q: If an anonymous user tries to view a protected page, he receives the login required "You must log in to view other pages" page instead of the wgPageSecurityErrorPage. Any suggestions?

A: When a anonymous user tries to access a page that is not allowed to him under MediaWiki built-in access control, MediaWiki shows the error page without calling the PageSecurity extension. I think this extension should not try to prevent this, because it tries to supplement the default MediaWiki behavior, not to replace it. I see two options:

1. If the anonymous user really cannot even see the page in question, leave it as it is. The default error message will inform the user that he can't see the page without logging in.
2. If anonymous users could see the page, just not edit it, don't configure MediaWiki so the page will be blocked to anonymous users. Leave it at the default settings where anonymous users can see the pages. Just use the PageSecurity extension to block edit access to it. --Fernando Correia 17:22, 24 January 2007 (UTC)

Q: Is there a way to apply a security extension ONLY if the person is anonymous?

A: I fear not. I will add it as a feature request. I think a good solution would be to create a pseudo-group named "anonymous". --Fernando Correia 10:57, 23 February 2007 (UTC)

I check some things and I do something about this, but, not in a very clean way... I see that if some definitions that deny an action to a group A and allows the same action to group B, the users in both groups are not allowed to do the action. This happend because the order of the checks in an internal function. I have a modified user:Fcarpani/PageSecurity Modified Version that invert the order with a new configuration variable $wgPageSecurityAllowGroupAccept. The implementation is veri dirty (only copy code) and can be made better if someone have some time. With this modification, now it's possible deny to '*' group and allow to some other group. I think that this modificaction also can induce some security hole that I can't see until now, but, it's possible. If someone see that, please talk about it!!!!!! Fernando Carpani 19:51, 22 February 2007 (UTC)

I wouldn't recommend that "allow" had a greater priority than "deny". It is usually accepted as a good security practice that "deny" has a greater priority. --Fernando Correia 10:57, 23 February 2007 (UTC)

In general, that is my position. In this particular case, I think that the inversion can allow a fine security definition like the previous. In some context this can be useful. In the other hand, this impose a more detailed knowledge about which user is in which group. The use this inversion in an environment with a too much users may be complex. This is because a user which can't access to a page P, must not belog to a group which can access to a page P. I think this in environments with a few users (less than 20 or 30) and they want to have some public (read) pages. This a quick solution, not a very safe solution and not the better. :-) Fernando Carpani 20:32, 26 February 2007 (UTC)

I've been thinking about this and I think it would be acceptable to let the sysop choose the rule order. So you could say "deny customers except customerA". I will add this as a feature request. The original question, anonymous access, would be better handled by a "virtual" user group for anonymous users. --Fernando Correia 21:05, 26 February 2007 (UTC)

Protecting templates

Q: How can I prevent the user from viewing the templates that I am trying to use as security templates?

A: You can solve that by using the PageSecurity extension to prevent read access to the security templates. One thing is to restrict access to pages that use a template. Other thing is to restrict access to the template itself. If you need both, you'll need more than one security definition. Though I don't think the security template itself is sensitive enough to need a specific protection. --Fernando Correia 17:22, 24 January 2007 (UTC)

postgreSQL

Q: May I use postgreSQL with PageSecurity?

A: I am using mw 1.9.2, winxpsp2, php 5.1.6, postgreSQL 8.1.7. I used the DB schema listed below, and it seems to be working ok. I have done a couple of tryouts. --Juan Gimenez

 CREATE SEQUENCE security_definition_id_seq;
 CREATE TABLE security_definitions (
 security_definition_id INTEGER NOT NULL DEFAULT nextval('security_definition_id_seq') PRIMARY KEY,
 security_definition_name TEXT NOT NULL,
 base_security_definition_id INTEGER NOT NULL,
 security_definition_notice TEXT NOT NULL,
 security_definition_logo TEXT
 );
 CREATE UNIQUE INDEX security_definitions_name ON security_definitions (security_definition_name);

 CREATE SEQUENCE security_definition_item_id_seq;
 CREATE TABLE security_definition_items (
 security_definition_item_id INTEGER NOT NULL DEFAULT nextval('security_definition_item_id_seq'),
 security_definition_id INTEGER NOT NULL,
 security_definition_item_action TEXT NOT NULL,
 security_definition_item_permission TEXT NOT NULL,
 security_definition_item_group TEXT NOT NULL,
 PRIMARY KEY  (security_definition_item_id)
 );
 CREATE INDEX security_definition_items_security_definition ON security_definition_items (security_definition_id);

RSS and Atom feeds

Q: Hi Fernando, first of all, thanks for your mediawiki extension! I've used it and works well. The question is focused on RSS feeds: I've inserted this line on config file (LocalSettings.php), to disable RSS feed:

// Disable feeds
$wgFeedClasses = array();

It is possible to enable RSS feeds reading in order to respect security rules? Only users with "rights" can read protected pages. Thanks!

A: It has been reported that in MediaWiki 1.10, still in development but already downloadable, Atom/RSS feeds will work with security extensions. I'll probably only verify this when this version is oficially released but you can try it if you feel like it. --Fernando Correia 12:26, 19 March 2007 (UTC)

If you don't use MonoBook?

Q: I'm not using MonoBook. How can I access the Security Definition Notice so it displays in my skin? Thanks!

Assigning All Newly Created User Accounts to Predefined PageSecurity User Groups

Q:

• I need to make sure that all users that create an account in my wiki (become authenticated users) are automatically assigned to a specific user group (other than the MediaWiki default 'user') in the process of the new user creating him- or herself a new account
• e.g. when user John visits my wiki first time and registers, then the user John will be automatically assigned to user group 'Customers' ...
• How do you do that ? Cheers, very nice extension ! KristjanLaane 21:55, 10 April 2007 (UTC)

Patches for 1.10.0?

Q: Are there patches available for 1.10.0? Will the ones for 1.9.3 work? --Swalsh 17:05, 17 May 2007 (UTC)

failed to return value under mediawiki 1.12

Q: After installing db and making all the orher stuff, i got a bug after including the PageSecurity.php in my local Settings. Main page isn't shown anylonger.

Detected bug in an extension! 
Hook fnPageSecurityUserCanHook failed to return a value; 
should return true to continue hook   processing or false to abort.
Backtrace:
#0 C:\Usb_Webserver\Root\mediawiki\includes\Title.php(1391): wfRunHooks('userCan', Array)
#1 C:\Usb_Webserver\Root\mediawiki\includes\Wiki.php(125): Title->userCanRead()
#2 C:\Usb_Webserver\Root\mediawiki\includes\Wiki.php(43): MediaWiki->preliminaryChecks(Object(Title), Object(StubObject), Object(WebRequest))
#3 C:\Usb_Webserver\Root\mediawiki\index.php(90): MediaWiki->initialize(Object(Title), Object(StubObject), Object(User), Object(WebRequest))
#4 {main}

but in PageSecurity.php i didn't modified this fn, so it's configured like:

// Handles the userCan event.
// $result = false if the $user is not allowed to execute $action on $title.
function fnPageSecurityUserCanHook($title, $user, $action, $result) {
   if (!SecurityManager::userCan($title, $user, $action)) $result = false;
}

Feature requests

• Automatically grant read access to the error page to avoid the possibility of a redirect loop.
• Simplify the installation process by creating some sort of script that automatically applies the necessary changes.
• Protect uploaded files. Should protect from image inclusion, viewing image pages and listing image URLs as in Special:Imagelist.
• [documentation] add the four steps described here as a summary of the installation & configuration procedure
• Apply security definitions (both allow and deny) to anonymous users by using a "virtual" use group named "anonymous".
• On each security definition, allow the "deny" rule to be specified before the "allow" rule. The order of specification will be the same order of evaluation.
• Only allow actions such as protect or delete if the user has "read" and "write" rights, or if he is a sysop and sysop access is allowed.
• Add a "talk" feature that can be used with the Talkright extension to allow access to the talk page without allowing "write" access.

Bugs

Long user group names (resolved)

Easyphp 2.0b1, MediaWiki 1.9.2, PageSecurity 1.1.3

Doesn't work if user group too long. requires modification of user group table (default to CHAR(15))

Antoine Sirianni 17:30, 21 February 2007 (UTC)

The MediaWiki core uses short user group names. The PageSecurity extension works with the core support for user group names. On my installation it is defined as CHAR(16). I wouldn't recommend changing this setting because it may affect other core functions. Resolution: not a bug. --Fernando Correia 10:53, 22 February 2007 (UTC)

Special characters in user group names (resolved)

Doesn't work if user group contains UTF characters like French ones. Example: Hélène

Antoine Sirianni 17:30, 21 February 2007 (UTC)

I have a security definition like this. The name of the security definition and the name of the user group are accented (Marítima):

<security-definition name="Marítima" base="Default"
  notice="Acesso - Marítima.">
  <allow action="read">Marítima</allow>
  <allow action="write">Marítima</allow>
</security-definition>

On LocalSettings.php I use this:

$wgPageSecurity[] = array(utf8_encode("Marítima"), "content", "\{\{Específica\|Marítima\|");

Please provide a sample of your equivalente configurations. --Fernando Correia 10:59, 22 February 2007 (UTC)

I retested my configuration and it works with special characters in user group names :-) The bug came from the 'long user group name' side effect only. I used VARCHAR(255) type for group names, the same as user names. It seems to be OK. Antoine Sirianni 08:17, 23 February 2007 (UTC)

I wouldn't recommend changing the maximum user group name length. This is a core MediaWiki setting, not something specific to the PageSecurity extension. It can have side effects, now or in future versions. I suggest asking the MediaWiki developers. Resolution: not a bug. --Fernando Correia 10:57, 23 February 2007 (UTC)

Sysop rights (resolved)

I have found one issue: Although administrator rights are disabled, ($wgPageSecurityAllowSysop = false) sysop can still protect or delete a secured page. Antoine Sirianni 08:17, 23 February 2007 (UTC)

The scope of the PageSecurity security extension is to control read and write access. It is an addition, not a replacement, to the access permissions that already exist on MediaWiki core. I think it is fitting that the sysops can protect or delete pages, this is their job. Anyway, I will make this into a feature request to only allow certain rights if "read" and "write" rights are also allowed. Resolution: feature request. --Fernando Correia 10:57, 23 February 2007 (UTC)

Maintenance Scripts don't work correctly

I have noted this on the main page in case it catches someone else out.

If you run refreshLinks.php to rebuild your link table, you end up with a nearly empty link table and therefore nothing in any categories. This is because that script calls getText in the includes/Revision.php file and it simply returns. Richard

Securing a page by Category

This issue occurred with MediaWiki version 1.9.3.

I had an issue securing a page via Category with a definition like this:

$wgPageSecurity[] = array("Policy", "content", "[[Category:Policy]]");

If a page contained a link (i.e. [[:Category:Policy]]) to the category then it improperly secured that page. It seems the perl regular expressions were going wonky over the "" and "".

To fix this I modified the function getPageSecurityDefinition in the file PageSecurity.php.

I inserted the code below after this line:

$protection_pattern = utf8_encode($expression[2]); 

Inserted:

$protection_pattern = str_replace("[","\[", $protection_pattern);
$protection_pattern = str_replace("]","\]", $protection_pattern);

Contributors

Source code contributors:

• Fernando Correia: Original contributor.

Version history

1.1.4

Release date: 2007-03-01

• BUGFIX: SkinFooterLinks hook chain was interrupted

1.1.3

Release date: 2007-02-20

• Published patches for MediaWiki 1.9.2.
• The main source code was not changed.

1.1.2

Release date: 2007-02-05

• Security fix: only sysops can save security definitions.

1.1.1

Release date: 2007-01-29

• Published patches for MediaWiki 1.9.1.
• The main source code was not changed.

1.1.0

Release date: 2007-01-24

• Added "logo" parameter to security definition.
• Changes the logo according to the page security definition.

1.0.0

Release date: 2006-12-15

• Initial release.

MW v1.10+?

Does this extension work with the latest version of MediaWiki? Is it still being maintained?
Also, are there any plans to make use of the protection features introduced in these latest versions?
-- 07:29, 3 August 2007 (UTC)

Related Example

I have the latest version of MediaWiki setup (1.10). I have gone through the instructions listed hereExtension:PageSecurity#Installation and upgrade to install the PageSecurity extension.

I receive the following error message when I go into MediaWiki..

Internal error
Detected bug in an extension! Hook fnPageSecurityUserCanHook failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

#0 /usr/home/citys2/www/htdocs/inhouse/wiki/includes/Title.php(1264): wfRunHooks('userCan', Array)
#1 /usr/home/citys2/www/htdocs/inhouse/wiki/includes/Wiki.php(133): Title->userCanRead()
#2 /usr/home/citys2/www/htdocs/inhouse/wiki/includes/Wiki.php(43): MediaWiki->preliminaryChecks(Object(Title), Object(StubObject), Object(WebRequest))
#3 /usr/home/citys2/www/htdocs/inhouse/wiki/index.php(89): MediaWiki->initialize(Object(Title), Object(StubObject), Object(User), Object(WebRequest))
#4 /usr/home/citys2/www/htdocs/inhouse/wiki/index.php5(1): require('/usr/home/citys...')
#5 {main}

Anyone have any idea what could be causing this, and even better, have a solution? -- 6 December 2007

Hi i have exactly the same problem, i am using the MediaWiki 1.10 and the error appeared when i created page Security definitions and saved it with the text. -- 7 February 2008

I'm using MediaWiki 1.12 alfa - the same problem.

-- 6 March 2008

Here is a fix for that problem. Locate the function fnPageSecurityUserCanHook in the extension file (line 94) and replace it with this:

function fnPageSecurityUserCanHook($title, $user, $action, $result) {
    if (!SecurityManager::userCan($title, $user, $action)){
    	$result = false;
    }
    return true;
}

That fixes the problem. There may be other fixes required - I'll check this page to see if you need further help (as this extension does not seem to be maintained anymore). -- 12 March

Doesn't work for me. I still get the same error. --Liface 09:56, 10 April 2008 (UTC)

Hello I have the same problem that Liface, I receive the following error message when I go into MediaWiki..

Internal error
Detected bug in an extension! Hook fnPageSecurityUserCanHook failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

#0 /usr/home/citys2/www/htdocs/inhouse/wiki/includes/Title.php(1264): wfRunHooks('userCan', Array)
#1 /usr/home/citys2/www/htdocs/inhouse/wiki/includes/Wiki.php(133): Title->userCanRead()
#2 /usr/home/citys2/www/htdocs/inhouse/wiki/includes/Wiki.php(43): MediaWiki->preliminaryChecks(Object(Title), Object(StubObject), Object(WebRequest))
#3 /usr/home/citys2/www/htdocs/inhouse/wiki/index.php(89): MediaWiki->initialize(Object(Title), Object(StubObject), Object(User), Object(WebRequest))
#4 /usr/home/citys2/www/htdocs/inhouse/wiki/index.php5(1): require('/usr/home/citys...')
#5 {main}

Someone have a solution ?

ParserOutput error

I'm running 1.11.1 The above solution fixed that error but this new error appeared.

Notice: Undefined property: ParserOutput::$mHTMLtitle in /home/livewel2/public_html/mediawiki/includes/OutputPage.php on line 341

Notice: Undefined property: ParserOutput::$mSubtitle in /home/livewel2/public_html/mediawiki/includes/OutputPage.php on line 344
MediaWiki internal error.

Same errors as above (vers. 1.13), found a fix (i think)

Running 1.13.2, I received the error:

Internal error Detected bug in an extension! Hook fnPageSecurityUserCanHook failed to return a value; should return true to continue hook processing or false to abort. [etc]

Pasted this fix into PageSecurity.php:

function fnPageSecurityUserCanHook($title, $user, $action, $result) {
    if (!SecurityManager::userCan($title, $user, $action)){
    	$result = false;
    }
    return true;
}

Still no Main Page. Checked the extension php for unwanted line terminations and changed double-quotes to single (except where double-quotes needed) and made sure variables were registering as variables.

Voila! It works.

I've begun porting to 1.18.1

As we need this extension to work at the company I work for, I have begun to port it to MediaWiki 1.18.1. My WIP can be found here: User:Zellfaze/PageSecurity Zellfaze (talk) 18:16, 24 February 2012 (UTC)

Work has pretty much finished. I tested out the basic functionality, and all seems to be in order. If anyone wishes to look over my work, I would appreciate it. I have added that there is a patch available to the patch page. Full work can also be found here: User:Zellfaze/PageSecurity. Zellfaze (talk) 21:09, 24 February 2012 (UTC)

Do you have plans to continue support for this tool?

I've been using your tool for quite some time (MW1.9.3) now and very happy with it. I recently installed MW 1.19.1.. but find a sentence at the top of the page saying it's apparently no longer supported. Are there plans to continue? or do I need to look for another solution?

Extension status?

This extension is listed as being in "Beta" but the latest version was 9 years ago. Any reason not to change status to unsupported?