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)

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.