Extension talk:SimpleSecurity

From MediaWiki.org

[edit] Special:Allmessages not readable

Since MW 1.10(.1) it is impossible to view Special:Allmessages, if the extension is enabled. You get only a white page (0 bytes) Ozz 09:03, 17 July 2007 (UTC)

[edit] ReadMe not readable

The link to ReadMe results in the message "Sorry, article not readable!". --Fernando Correia 12:13, 2 March 2007 (UTC)

Oops sorry! fixed now ;-) --Nad 14:10, 2 March 2007 (UTC)

[edit] Latest revision not working for 1.8.x

Downloaded the version available at the time of signing this. Complained about use of $this outside of a class. So, I changed $this to $thisref. Then, I get flooded with errors. --Michael Reynolds 18:55, 7 March 2007 (UTC)

Thanks for the info, its working on 1.6.x but hasn't been tested for 1.8.x yet --Nad 22:01, 7 March 2007 (UTC)

Looks extremely promising, so it's well worth me waiting. If needed, I can provide some testing. I've a knack for finding ways to break things. - Michael Reynolds 09:14, 8 March 2007 (UTC)

Any feedback is welcome - I'm installing a 1.9 at the moment which I'll test it on. --Nad 10:13, 8 March 2007 (UTC)

I've got it working on MediaWiki 1.9.3 and added a section for testing feedback. Some of the trouble was with PHP4-specific code, but all ok now, hopefully it'll work on your 1.8.x install ;-) --Nad 08:51, 9 March 2007 (UTC)

Ooops sorry, I tell a lie! I'm getting to tired - I've got it working for PHP5.2, but only on MW1.6.7 - still not working on 1.9.x, but should be ready soon I'd say... --Nad 08:57, 9 March 2007 (UTC)

Well I'm almost ready to give up on 1.9, $parser->setFunctionHook seems to work a different way or something - I can't get MW1.9 to call my parser hooks at all!? --Nad 12:05, 9 March 2007 (UTC)

When I get some free time, I'll look at it and see if I can figure out the parser hooks. Maybe tonight or tomorrow morning. --Michael Reynolds 19:04, 9 March 2007 (UTC)

Thanks a lot that would be cool - my 1.9 install is www.wikifs.org and the code it's using is included from the LocalSettings.php file and is directly included from the OrganicDesign:MW1.9_Security.php article which is in a different wiki so it doesn't matter if changes to the code break the 1.9 wiki. --Nad 20:05, 9 March 2007 (UTC)

Looks like it's simply that the syntax requires the preceding hash in 1.9.x but not 1.6.x! --Nad 20:53, 9 March 2007 (UTC)

You wouldn't happen to use IRC or an instant messenger of some sort? I'd like to discuss the workings of this extension with you in semi-realtime, which has the added bonus of not cluttering up the talk page. As an aside, do you need a mailing list for the project? If so, I can offer you use of my mailing list system. --Michael Reynolds 21:33, 10 March 2007 (UTC)

I don't have any IRC sorry, my main communications is on OrganicDesign:User talk:Nad, or my email which is aran @ that same domain. Thanks for the mail-list offer, but I don't think we need one just now. I was thinking of integrating some kind of chat extension into our wiki, but haven't had the time to check it out yet. --Nad 22:22, 10 March 2007 (UTC)

A friend of mine is starting an extension to incorporate a SWF IRC discussion component into MediaWiki at http://www.wikichat.org --Nad 03:32, 11 March 2007 (UTC)

[edit] Malicious usage

Well, I have read this article twice. Basically, this extension would do what I want to do: Let certain pages only be editable by a specific user (and viewable by everyone else).

However, if I switch this extension on, what's to keep random Joe from locking down a perfectly good article by inserting {{#security:edit|Joe}}, and therefore keeping anyone else from editing?

I am sure I am only reading this wrong. In that case please take this as suggestion to include an explanation of how it works in the article. --Icekiss 20:10, 31 March 2007 (UTC)

The $wgSecuritySysops global contains a lost of all the groups or users which bypass the security, by default this is just the sysop group. --Nad 21:47, 31 March 2007 (UTC)

Well, as a sysop I'd have better things to do then opening the pages back up. Just trying to correct the damage after it has been done seems broken to me (unless you allow all wiki users to do it, which would make it pointless...)

If this extension really does allow anyone to lock down any page, then it's not what I am looking for after all. Thank's anyway. Icekiss 15:30, 3 April 2007 (UTC)

[edit] SS overriding basic page protection

I have a need to ensure that basic mediawiki settings such as page protections are not overridden by this extension. Is that possible ... for example all protected pages after applying this extensions are now opened to edit by anyone -- User:Vasu

Thanks for the feedback, I've added this problem to the bug list to fix when I can get some time on it. --Nad 21:50, 17 April 2007 (UTC)

Hi Nad, I'm actually coming at this one from the opposite direction. I'm currently using $wgGroupPermissions to restrict all wiki access to only users in a group named 'engineers'. However, there are a limited number of pages that we've added to a Category named 'Public' and would like to make available to a wider audience. Unfortunately, a directive of {{#security:view|*}} added to the category page does not seem to override the (more restrictive) security already set by $wgGroupPermissions. Do you know if there is any way to achieve this 'default deny, but selective allow' model via the current extension? I do realize I could just use $wgWhitelistRead, but that is undesirable as it would require users to have shell access any time they wanted to add a new public article. Thanks for your advice :) --210.84.54.126 14:41, 28 May 2007 (UTC)

I actually have almost exactly the same requirement on many of the wiki's I've set up for intranets where they deny all by default but allow full access to the public category, how I do that is outlined at OrganicDesign:Maintaining websites with a wiki. This is slightly different than the way you're needing it but you should be able to adjust it to your needs. --Nad 21:12, 28 May 2007 (UTC)

[edit] Secure content displayed

I gave a try to Security Extension and did not have any luck on setting permissions. The Deny Template is never parsed on resticted pages, they show always their content no matter if users are allowed to see them. Only when resptictes pages are eddited, the deny template finally appears. Has anyone had this issue ? User:lmonzalvo

Could you give me a URL so I can see this happening? or otherwise show me the security directives being used and the global security variables values and MediaWiki version etc --Nad 21:48, 17 April 2007 (UTC)

Hi, I try to use {{#security:*|user}} but the content is already displayed for a non logged user. Is is right ? i use php5 ans MW 1.9.3 --Ouaibsky 11:48, 15 May 2007 (UTC)

[edit] Problem with multiple rules

Security rules on the page were:

{{#security:*|Vhermecz}}

I modified it to:

{{#security:*|Vhermecz}} {{#security:view|Stupid}}

(I made all actions with user Vhermecz) After mofification Vhermecz could not access page contents

That makes sense, since only user Stupid should be able to access it after that change. Are you meaning that a user shouldn't be able to add security that makes it inaccessible to them? I've added that to the todo list --Nad 20:55, 27 April 2007 (UTC)

[edit] Anonymous Users vs. Everyone Else

I'm looking to completely lock out certain pages on my Wiki from anonymous users (I don't even want them to be able to view these pages); but I'm OK with allowing all users who are signed in to be able to do whatever they want with those same pages. An * in the "actions" part of the directive means "use the default permissions"; what does an * in the users side mean: all users, or all registered users? --Dataweaver 19:16, 30 April 2007 (UTC)

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. --Nad 22:18, 30 April 2007 (UTC)

I've tried this. Unfortunately, my wiki is behaving as if the group 'user' doesn't exist: the only people who can access the pages that I restrict to 'user' are the Sysops, who by definition are able to ignore the security restrictions. --Dataweaver 13:50, 3 July 2007 (UTC)

[edit] Extraneous Code

I have a page that has been secured using {{#security:*|user}}, and I've streamlined the "Action not permitted" Template. When I log out and try to access the page, I get the following:

I have attempted to fix the problem by removing "Template:" from the default values of $wgSecurityDenyTemplate and $wgSecurityInfoTemplate. Doing so doesn't break the functionality at all, but it still doesn't remove the trailing {{...}} from the error message. --Dataweaver 09:17, 1 May 2007 (UTC)

I found a bug which made that wikitext show up and fixed it, so if you download again it should be fine. --Nad 10:03, 1 May 2007 (UTC)

Got it. --Dataweaver 10:11, 1 May 2007 (UTC)

[edit] Minor patch

I've applied the following patch to the file:

@@ -132,7 +132,7 @@
                        $info = '{'.'{'."$wgSecurityInfoTemplate|1=\n";
                        foreach ($rules as $rule) {
                                $a = $rule[0] == '*' ? 'Every action' : ucfirst($rule[0]);
-                               $b = $rule[1] == '*' ? 'anybody' : $rule[1];
+                               $b = $rule[1] == '*' ? 'anybody' : ($rule[1] == 'user' ? 'logged in' : $rule[1]);
                                $c = isset($rule[2]) ? " ''($rule[2])''" : '';
                                $info .= "*'''$a''' requires the user to be '''$b'''$c\n";
                                }

This makes Info messages involving the user group render as a requirement that the user be logged in for the action(s) to be available. --Dataweaver 10:11, 1 May 2007 (UTC)

Sorry I didn't notice this change before - good idea, I've updated the file ;-) --Nad 04:25, 15 May 2007 (UTC)

[edit] How I use this patch on the file in Win XP

Sorry, I don't know how to use this path. Could Anybody gave me a hand?

• OS Win XP
• Apache Web Server Version 2.2.3
• PHP Script Language Version 5.1.6
• MySQL Database Version 5.0.24a

--Roc michael 03:04, 15 May 2007 (UTC)

The patch is just a minor fix to the output template, not critical. I've added the patch to the code, OrganicDesign:Extension:SimpleSecurity.php --Nad 04:32, 15 May 2007 (UTC)

[edit] Another Minor patch

I haven't yet implemented this patch; but the principle is sound. The idea is to add a third template that supplements Template:Security info, thus allowing more control over the presentation of the individual rules. In short, replace

                           $info .= "*'''$a''' requires the user to be '''$b'''$c\n";

with

                           $info .= "{{$wgSecurityInfoTemplate (rule)|$a|$b|$c}}\n";

The supplemental template is called Template:Security info (rule) (or whatever $wgSecurityInfoTemplate is set to, followed by ' (rule)'); a good default template would be:

*'''{{{1}}}''' requires the user to be '''{{{2}}}'''{{{3}}}

If there's a way for templates to include parameter-based conditionals, I'd further recommend streamlining $c to the name of the Category being inherited from (or '' if none), and placing the "this rule is inherited from ..." verbage in a conditional block in Template:Security info (rule). If not, the above approach is the simplest compromise. --Dataweaver 08:54, 15 May 2007 (UTC)

I've just added a global called $wgSecurityRuleTemplate so you can set it to any article to use as the rule-message template, and if left empty it will use the current message. --Nad 09:51, 15 May 2007 (UTC)

[edit] $wgSecurityGroupsArticle usage ?

How to use this feature ? If i understand, i need to create an article, but what is the syntax/format of this article ? And how to fill this variable ? An example should be fine Thx --Ouaibsky 11:50, 15 May 2007 (UTC)

Sorry, I missed this question before - the Groups article is just a bullet list of group names --Nad 06:35, 11 July 2007 (UTC)

[edit] Ask new feature: group definition extension

Actually, group definition and management is not very easy into mediawiki. Today simpleSecurity extension use the native UserRight managment, $wgSecurityGroupsArticle is a begenning but not enough. Is it possible to extend group resolution like this another group permission extension: Extension:Group_Based_Access_Control#Features. The idea is to delegate the group management at different users for several pages/categories. Thx --Ouaibsky 11:59, 15 May 2007 (UTC)

I think the current method using $wgSecurityGroupsArticle is enough to do what you're wanting, just add as many new groups into that article as you like (a normal bullet list of group names), then go to Special:Userrights as usual and assign the users to the new groups. I don't want to add any more non-trivial features to SimpleSecuriy at the moment because I need to get it working properly first, it's still got some major problems that need fixing. --Nad 22:15, 15 May 2007 (UTC)

[edit] Denying anonymous read access globally

I would like to deny anonymous read access on a global level. Before Simple Security was securing individual pages, I used the $wgGroupPermissions['*']['read'] = false; line to control read permissions. However, now that your extension is installed, this has been completely changed even though the wgGroupPermissions command is still present. How do I disallow read on a global for anonymous users without editing each individual page?

It shouldn't have been affecting the $wgGroupPermissions['*'] operation, that was a bug which is fixed now (I hope), try downloading the current version now. --Nad 22:45, 18 May 2007 (UTC)

That's perfect, works great now. Thanks! -Chris

[edit] Permissions on Special Pages

Would it be possible to set permissions on special pages? I don't want just any user to be able to see a file list, a list of users, etc.

I may add the ability to specify page permissions from an array at some stage, but in the mean time you'd have to disallow anonymous viewing and then add selected special pages to the $wgWhiteListRead global --Nad 00:53, 22 May 2007 (UTC)

Well, actually what I'd have to do is set wgGroupPermissions['user']['read'] = false; which would deny all logged in users the read permission. And then, I'd have to white list all the special pages I want available. Only problem with this is that even the pages I want them to access, which I have secured with your simple security, are unavailable because read permissions are denied globally. I almost need an ability to black list globally, for certain user groups. Any ideas? -Chris

If you're using 1.9.x you can hook into the SpecialPage_initList hook which allows you to modify the list of available specialpages, which you could then filter based on $wgUser->getGroups() --Nad 22:06, 22 May 2007 (UTC)

Ok, I'm not that smart :-) I am using 1.9.x but I have absolutely no clue how to do what you just specified. - Chris

Add the following code snippet to your LocalSettings.php file, and change the group name from "specialGroup" to whatever your privileged special-pages viewing group is. --Nad 02:31, 23 May 2007 (UTC)

$wgHooks['SpecialPage_initList'][] = 'wfRemoveSpecialPages';
function wfRemoveSpecialPages(&$list) {
global $wgUser;
#if (!in_array('specialGroup',$wgUser->getGroups())) {
        unset($list['File list']);
        unset($list['Gallery of new files']);
#     }
return true;
}

I added that code to LocalSettings.php, changed specialGroup to the group I wanted permissions denied to, cleared my browser cache, logged in, and absolutely no difference. I really appreciate your help on this! -Chris

If the users in the specialGroup are being denied, you need to remove the "!" in the code above, because currently it says you have to be in the group to see the specialpages. Try commenting out the if like I've done above to test whether removing them is working on your wiki, and then after that works, add in the condition by which the removals should happen. --Nad 22:24, 23 May 2007 (UTC)

I just added the code with the if function commented out and it looks like my wiki is not removing them. -Chris

Sorry I don't know what else to suggest, I've tested the code on a 1.9.x and it removes the specified pages, in this case just the file-list and gallery....? --Nad 02:40, 24 May 2007 (UTC)

I found a way to do it. Not as clean as yours, but it works! I edit each type of special page in /includes/SpecialPage.php like the following. It restricts that special page so that only those in the 'employeeGroup' can access. Thanks again Nad! - Chris

'Imagelist' => array( 'SpecialPage', 'Imagelist', 'employeeGroup' ),

[edit] Please add in line 190..

Hi Nad, please replace

  elseif ($wgUser->mDataLoaded) {

with

  elsif (!empty($wgUser->mDataLoaded)) {

in line 190. That will avoid the errorlog running full with PHP notices of undefined properties. --Xwolf 08:46, 24 May 2007 (UTC)

done --Nad 11:15, 24 May 2007 (UTC)

[edit] How users use this extension with Chinese names

Hi Nad, If a user uses Chinese character for he's or her account like "張三" ,we see it as "", I guess that this excellent extension wouldn't help the user. Right? --Roc michael 14:19, 26 May 2007 (UTC)

You'll have to tell me what goes wrong with those characters exactly and I'll see if I can fix it to work properly --Nad 23:12, 27 May 2007 (UTC)

In usage_examples, it said"Users names start with an uppercase letter". Every Chinese character is not case sensitive. So Chinese people may use this extension to assign authority by groups only "We sysops can rename all group name in English but Chinese users name still use Chinese).Roc michael

Good point, I'll add a note to the todo list to fix that --Nad 19:57, 24 June 2007 (UTC)

[edit] Security on images & files

I'm attempting to install security for files & images on my 1.9.x wiki. I add the Mod-Rewrite code to my httpd.conf file, correct? The security does not seem to be working when I do that. -Chris

Does the rewrite rule you added to your wiki's virtual host container match the path your wiki uses? and is Apache definately loading mod-rewrite?

I posted this code:

RewriteCond %{REQUEST_URI} ^/images/.+
RewriteRule ^/images/(.+) /index.php/Download/$1 [L]

into my virtual host container for the domain that the wiki is on (it actually has it's own virtual host container) and restarted apache. Nothing happens. When I attempt to access a file directly (http://wiki.domain.com/images/3/3b/protectedfile.doc) the file is still accessible even though I've protected it on the Image:Article page. The files are located at /var/www/mediawiki/images and of course /var/www/mediawiki/index.php. Mod-rewrite is reported by my phpinfo page to be installed and fully functional. -Chris

You can check if its mod-rewrite or the simple-security that's failing by commenting out the simple-security include directive in localsettings but keep the rewrite rule active. When you request that image-url in the browser you should end up at a non-existent wiki-article called Download/3/3b/protectedfile.doc, if not then the mod-rewrite rule isn't being executed. --Nad 01:07, 30 May 2007 (UTC)

Oops - actually there's a line missing which I've just added, you need to turn the rewrite engine on by inserting RewriteEngine On before those two rewrite directives in the vhost container. --Nad 01:11, 30 May 2007 (UTC)

Yep! That was it. I added the following code to my httpd.conf file (not the virtual host container) and it works like a charm now. -Chris

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/var/www/mediawiki/images/.+
RewriteRule ^/var/www/mediawiki/images/(.+) /var/www/mediawiki/index.php/Download/$1 [L]

Well, not so fast. I'm having trouble with a 21MB zip file being denied, even though I have access and the file does indeed exist. Smaller files work perfectly. -Chris

Hmmm, I'll check it out - the larg files problem could be due to the fact that it's reading the whole file into PHP and then echoing it to the client. I did it like that because some clients require it to be gzipped, but there's probably a better way to do that. --Nad 20:56, 30 May 2007 (UTC)

I've attempted a fix on the problem, but can't test it here since my bandwidth is too low to receive a large enough file to cause problems... see if it works for the large files now? --Nad 07:59, 31 May 2007 (UTC)

After updating to your new revision, images no longer show up. Just the Image:imagename link. I'm using Firefox 2.0.0.4. -Chris

I've reverted back to 3.4.4 until I can get some more time to look in to it --Nad 01:39, 1 June 2007 (UTC)

Any word on looking into this issue? -Chris

I haven't had time yet, but I should be testing the download-security this week, and will add info here after that --Nad 06:35, 11 July 2007 (UTC)

[edit] MediaWiki 1.10 Question

Has anyone gotten this to work in MediaWiki 1.10? I installed it on our server but it doesn’t seem to work. There are no visible errors generated and it seems to get recognized by the wiki but the rules are not implemented. I tried restricting edit rights to a page, restricting view rights, allowing edit for anonymous users, etc .. I turned cache off also, but the rights seem to be always over ridden by the wiki settings. Please help.

I'm running it on a variety of versions from 1.6.x up to 1.10 and it works fine - by fine I mean that it works with all the security holes as discussed in the article, which is not really "fine" at all, but will do for now :-/

Is the wiki it's running on publically accessible so I can have a look at the problem? --Nad 22:37, 16 July 2007 (UTC)

Unfortunately it is running on a closed internal network for the time being. It is good to know that it runs on wiki 1.10. Maybe if I give a little more detail it might help. I have the security set up so all users have total access to pages and I would like SimpleSecurity to restrict edit rights to some pages. Is this possible? Is my Wiki right over riding the SS rights? Are there some global settings I got to set? Is there specific place on the page I got to put the SS tags in? What are some steps I can go though to test and make sure things are installed and working right? Thank you for your help!

I don't know what it can be, it should be able to work with nothing but the include line. What is the exact syntax you're using to restrict the rights of your test page? --Nad 21:24, 17 July 2007 (UTC)

I'm just trying the default syntax from this wiki page {#security:view,history|staff,consultants}} for some reason the wiki default security settings seem to override the SS settings. Any ideas? Thank you!

[edit] Can't get it to work on 1.6.10

I just tried this extension on 1.6.10 (PHP 4.3.11/MySQL 4.1.12) - as soon as I include it, any page I tried to read displayed the "Action not permitted" template, though "edit" still worked. This despite the fact that I was sysop and had not added any security settings to any page yet. Also, the template wasn't even shown correctly - it looked like the two arguments were missing in whatever called the template (I'm using the one given as example), i.e. the spaces before and after "action to be performed on the" were empty. Any idea? --Emgaron 14:49, 19 July 2007 (UTC)

I have it running on a 1.6.10 at http://www.peerix.org, on 1.6.x you need to add the hashes manually if you want them in the parser-function name, and you'll need to tell it to parse the security template, so your LocalSettings code to set it up should look something like this,

include("$IP/extensions/SimpleSecurity/SimpleSecurity.php");
$wgSecurityMagic             = "#security";
$wgSecurityMagicNoi          = "#!security";
$wgSecurityMagicIf           = "#ifusercan";
$wgSecurityMagicGroup        = "#ifgroup";
$wgSecurityParseInfo         = true;

I've added those (in fact, I had them already, except for the "$wgSecurityParseInfo"), but unfortunately, that didn't change anything - still the same problem. I've also verified that the Template works normally by including it into another page manually. Also, the plugin does register itself properly according to the Version page. Could it be some download error? I copied and pasted the plugin from your wiki, as I didn't see any way to download the file itself - or did I miss something? --Emgaron 07:18, 23 July 2007 (UTC)

I'm one step further - I just found an error message in my error_log. It says:
PHP Notice: Undefined property: initialised in /var/...../SimpleSecurity.php on line 201...

That's the following code fragment in function "onuserCan":

if ($this->initialised) {
        # we can call $this->validate in here so mediawiki can render links according to permissions
        }
elseif (!empty($wgUser->mDataLoaded)) {

This warning/error is due to a typo in SimpleSecurity.php - you have a var $initialsed; in "class SimpleSecurity" - this should of course be var $initialised;. Unfortunately, this does not solve my original problem... :-( --Emgaron 13:39, 23 July 2007 (UTC)

More info: I've done some experimenting (added debug output to each function just to see which functions are called) and it seems that onuserCan is never run when viewing a page. That would be consistent with the fact that $this->action is not set (its place in the template is empty). It would, however, not explain why $this->allowed is no longer its default value "true"... --Emgaron 15:16, 23 July 2007 (UTC)

Scrap that - onuserCan is run properly. I'm just after running quite a few tests and came up with this:

• In onuserCan, $this->action, $this->title and $this->allowed all get their proper values ("allowed" is true, just like it should be for a page that has no restriction on it). I've verified that using "echo" statements in the code.
• However, right at the start of onOutputPageBeforeHTML, $this->allowed is now false and the other two variables are not set (also verified with "echo" statements).

Admittedly, my understanding of PHP is rudimentary, but to me this looks like the "$this" variables are not passed on the way they should be. Could this be some PHP4 vs. PHP5 issue or some config setting for PHP? --Emgaron 07:57, 24 July 2007 (UTC)

Confirmed - if I replace occurrences of $this with global variables, the plugin starts to work. Hence, something is wrong with $this in our PHP 4.3.11 installation... :-( --Emgaron 09:44, 24 July 2007 (UTC)

Has there been any progress on this bug? We are suffering from the same symptoms at www.wikipaltz.com. I don't know enough PHP to patch together a fix for our site. RadicalHarmony 00:50, 14 April 2008 (UTC)

[edit] Security working but actions a bit mixed up

When I use a directive such as:

{{#Security:edit|Rcar004}}

The extension correctly excludes other users from editing and displays the template. However it misleadingly says something like:

No Access: Your access rights do not permit you to view People/Mr_Robert_Carter.

Where it says view it should say edit. So no real problem, just the text output. Will be doing some more testing this week so i'll report any other things I find here. --Rob 22:30, 7 October 2007 (UTC)

Around line 156 there is some stuff with int indexed arrays so maybe the indexes got mixed up? --Rob 22:32, 7 October 2007 (UTC)

This is a known bug which is in the pipeline to be fixed --Nad 23:15, 7 October 2007 (UTC)

One other thing: I noticed that the page name that is substituted into the template is like the magic word {{PAGENAMEE}} when it should be the human version: {{SUBPAGENAME}} for example. --Rob 22:41, 7 October 2007 (UTC)

[edit] Calling security functions in other extensions

I use DynamicPageList extension to display latest and popular articles of my wiki. How can I use the SimpleSecurity extension's function in that extension's code to hide restricted articles from being displayed. this is achieved in TransformChanges extension. so i tried to make something out of it. i added

global $wgSimpleSecurity;
$allowed = is_object($wgSimpleSecurity) ? $wgSimpleSecurity->validateTitle('view',$aArticles[$i]) : true;
if ($allowed) 
$r .= $sStartItem . $aArticles[$i] . $editorString . $dateString . $viewString . $sEndItem . "\n";

in the function OutputList. i'm getting a blank page. if i comment the $allowed = $wgSimpleSecurity->validateTitle('view',$aArticles[$i]) line, it's working (but the restricted articles are displayed).

any suggestions, plz.

You might be getting a blank screen due to an error occurring but not have error reporting enabled in php.ini. The error could possibly be that your php.ini is set to strict and the $allowed variable was not being set, I changed the code above to ensure that $allowed is set whether or not simple security is detected, but that's unlikely to be the problem, so you need to turn on error reporting or check the error log to find what error is happening. --Nad 20:12, 16 October 2007 (UTC)

Thanks Nad..but it didn't solve the problem. Regarding error reporting also, I have a strange problem with my MW. though display_errors=on and it's set for ALL, MW is not displaying any error messages for me, except the internally triggered error messages. i set the value for an error log file also, but with the modified $allowed line, nothing is logged or displayed. but for other php applications, errors are displayed and logged. i even added ini_set( 'display_errors', 1 ); and error_reporting( E_ALL ); to the beginning of my localsettings.php, but no luck. what to do..

[edit] Works on MW 1.12a BUT ...

So far it works OK - still must try different security examples .. Not sure if this should happen but the "Template:Security info" template shows up correctly when an anonymous caller tries to view page (and he is blocked) but it also shows up when a valid user views the page (but he can view the page) - As he has the privileges anyway, why show the template ?? ..

I used "{{#security:view|user}}" on a page ...

How can I stop the template showing for valid users ?

--Dick 22:09, 21 October 2007 (UTC)

I'm working on a new version now which will solve that problem (it just puts a small padlock before the title and you can click that if you want the details) --Nad 21:19, 22 October 2007 (UTC)

I find that if I take off the wiki edit restriction (enable edit for all users) from a page (Current events page) and I have "{{#security:view|user}}" on that page, an anonymous user can click on edit and delete the one line of text from the edit page .. The text shown in the edit box is "{{Template:Action not permitted|fetch|Current events}}" .. The actual text of that page is not shown here! .. He can then save the page and when a valid user (logged in user) calls that page, its empty, original text deleted !!!

It appears that I must secure all pages from editing because when the anonymous user tries to read the source, he sees the same one-line text but can't do anything to it ...

But this modus operandi seems to defeat the object of this extension to do the relevant protection, doesn't it ??

--Dick 07:13, 22 October 2007 (UTC)

There have been some major problems showing up on various installations and mediawiki versions, I'd recommend waiting for the next version. SimpleSecurity was written for mediawiki 1.4.x and has had many patches added over the last year or two. The next version which should be released soon is almost a complete re-write and will be much more robust. --Nad 21:19, 22 October 2007 (UTC)

[edit] Search shows pages the user can't read

> # Search article: Do you get results with partially displayed text?
> See also bugzilla:8825

Appling that patch http://bugzilla.wikimedia.org/show_bug.cgi?id=8825#c1 does not help :-(

There are numerous problems with this extension currently. Version 4 is under way which addresses all of the issues discussed in Security issues with authorization extensions by dynamically creating a hook into the database row fetching method. --Nad 20:15, 12 November 2007 (UTC)

[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');

...

Insert this FROM LocalSettings.php? To WHERE?

I can't get it work for me because I just don't understand those installation instructions. And do i need add all those parameters in table to LocalSettings then?

Just add the include line into your localsettings the same as any other extension. --Nad 20:28, 19 December 2007 (UTC)

[edit] Ver 4.0.9

Nad, I had ver 3.4.8 running OK here on MW 1.12 but when I tried using ver 4.0.9 I get the dreaded 'white screen' - no wiki ..

I didn't do any other editing, just replacing the old version with the new version .. To get my wiki again, I reverted back to ver 3.4.8 ...

Did I miss something ???

--Dick 10:01, 9 January 2008 (UTC)

[edit] call #security on template and multiple include template in a page

• I define a template with security tag => OK
• I call this template from many page => OK
• I create a page and include into it many other page (which each include the template) => it works but many line are showing at the top of the page (many lines for the same security rule)

it's easy to reproduce: make add security rule into a template and include it many time.

I don't know if there is a workaround (whith parser extension or someting like that).

Thx in advance. -- Christophe. --Ouaibsky 13:07, 9 January 2008 (UTC)

[edit] Is there a way to install this on 1.5.8?

I have Mediawiki 1.5.8 and cant update...if I try to install this extension the only result I get is the extensions php-code being shown on top of every page. I would appreciate if someone could help me. 217.94.236.195 13:07, 2 March 2008 (UTC)

1.5.8 is far too old, if you're stuck because you're on PHP4 you can still upgrade to 1.6.10 which is much more supported than 1.5.x --Nad 20:15, 2 March 2008 (UTC)

PHP is not the problem. But MySQL is 3.something. Hmm..maybe I can get the hoster to upgrade MySQL.80.152.220.54 07:25, 3 March 2008 (UTC)

If the PHP is modern it may have PDO::SQLite 3.x installed - do a <?phpinfo();?> to check - you can run MediaWiki with SQLite now instead of MySQL --Nad 08:29, 3 March 2008 (UTC)

Well...I transfered to another host and updated to MediaWiki 1.7. But the results are still the same. :-( Its just showing the code on top every page instead of executing it. 217.94.250.44 11:57, 3 March 2008 (UTC)

Why on earth would you update to 1.7??? that's still a really old and unsupported version, if you're on a new host upgrade to 1.11 --Nad 21:09, 3 March 2008 (UTC)

Nevermind, got it to work. But thanks anyway. 80.152.220.54 09:15, 4 March 2008 (UTC)

[edit] How I´m using it...might be of use to someone

I use the "Simple Security"-Extension together with a selfmade template. {{lock}}. Inside the template I have the call to the Simple Security extension and a parameter: {{#security:edit|{{{1}}} }}. And a "Sorry, you´re not allowed to do this" message. By this, any user who wants to make sure others can´t edit a page he/she started just needs to call the "lock" template by putting his/her username as parameter {{lock|Username}}. Putting additional user names or names of user groups into the parameter seperated by "," will make the page editable by those users or groups. 217.94.236.47 16:44, 4 March 2008 (UTC)

[edit] Is it possible to restrict search based on Simple Security??

I was thinking of adding to the SearchEngine.php to work with SSecurity but not sure if it's possible. Like Group A can't search Group B's articles.

.. Any suggestions would be welcomed.. thanks.

The issue with your approach is that you are hacking the core codebase of the instance of MediaWiki you are using. This locks you into that version from there on in, unless you spend time to get it going with each new version of mediaWiki itself. A better approach is to utilize the call back functionality in extensions which is independent of code base versioning. Nad created an extension Extension:DatabaseFetchHook which is working towards addressing the security holes such as the one you have described --Zven 21:10, 15 May 2008 (UTC)

[edit] does not work in wiki 1.12?

having issues to make it work with wiki 1.12.0, totally bypasses the security directive,

downloading SimpleSecurity4, gives me errors, Warning: Wrong parameter count for preg_replace_callback() in /home/che/public_html/wiki/extensions/SimpleSecurity4.php(181) : eval()'d code on line 6

It doesn't work on modern versions and can't be trusted as it was designed for a very old version of MediaWiki. A new version is in development which is designed to extend MediaWiki's native permissions mechanism. --Nad 08:17, 17 July 2008 (UTC)

[edit] ifUserCan bugfix

-
        public function ifUserCan(&$parser, $action, $title, $then, $else = '') {
                return $title->userCan($action) ? $then : $else;
        }
+
        public function ifUserCan(&$parser, $action, $title, $then, $else = '') {
                $oTitle = Title::newFromText( $title );
                return $oTitle->userCan($action) ? $then : $else;
        }

otherwise it will crash as title is simple string

--Eugenem 13:10, 10 August 2008 (UTC)

oops, thanks will update asap :-) --Nad 11:17, 12 August 2008 (UTC)

[edit] doesn't work in MW 1.13

Fatal error: Call to a member function closeAll() on a non-object in /sites/jewage.org/wtest/extensions/SimpleSecurity/SimpleSecurity.php on line 295