Extension talk:SimpleSecurity/Archive

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)

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 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)

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, 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)

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)

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   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)

Problem with multiple rules
Security rules on the page were: I modified it to: (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)

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  , then all actions require the user to be logged in. --Nad 22:18, 30 April 2007 (UTC)

Extraneous Code
I have a page that has been secured using, 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)

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)

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? --Roc michael 03:04, 15 May 2007 (UTC)
 * OS Win XP
 * Apache Web Server Version 2.2.3
 * PHP Script Language Version 5.1.6
 * MySQL Database Version 5.0.24a
 * 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)

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 .= " \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:

* ' requires the user to be '

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)

$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)

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. 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)

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

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)


 * 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

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)