Extension talk:SimpleSecurity/Archive

Problems with accents (SOLVED)

Hi, I'm trying to add some category restrictions, some of them has spanich accent (i.e. 'Teoría'). It seems that the category blocking of the ones with accent doesn't work. Any idea of how could be solved? Alberto --212.166.232.132 14:30, 25 October 2010 (UTC)

Ok, I could find the solution here. You have to save the LocalSetting.php in UTF-8 without BOM codification. It was really easy using Notepad++ as an editor.

ifUserCan bugfix (resolved)

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

it's still not in trunk (2.4.8) :) -- ZoTyA 11:21, 28 August 2008 (UTC)

Is it gonna show up in trunk anyway? It's still not in yet -- ZoTyA 17:25, 2 September 2008 (UTC)

doesn't work in MW 1.13 (resolved)

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

The call to closeAll() fails because $wgLoadBalancer has been removed from this version of MW. Manual:$wgLoadBalancer

I've done it a simpler way now that intercepts database requests without needing to deal with the load balancer. I'll update it soon, but have to finish the category and namespace permissions first. --Nad 11:58, 23 August 2008 (UTC)

errors with 1.10.1 (resolved)

Notice: Undefined variable: DBtype in /var/wwwdata/applications/mediawiki/extensions/SimpleSecurity/SimpleSecurity.php on line 63

This is just php being pedantic.

Warning: preg_replace_callback() [function.preg-replace-callback]: Unable to call custom replacement function in /var/wwwdata/applications/mediawiki/extensions/SimpleSecurity/SimpleSecurity.php(416) : eval()'d code on line 4

Not too sure what's going on here.

Database error
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

    SELECT rev_page FROM `revision` WHERE rev_text_id = LIMIT 1 

from within function "SimpleSecurity::validateRow". MySQL returned error "1064: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the right syntax to use near 'LIMIT 1' at line 1

Looks like it's missing something after the rev_text_id =

• MediaWiki: 1.10.1
• PHP: 5.2.0-8+etch11 (cgi-fcgi)
• MySQL: 5.0.32-Debian_7etch6-log

--Rob 20:02, 24 August 2008 (UTC)

These bugs are all fixed now I think, plus a couple of others too ;-) --Nad 06:28, 26 August 2008 (UTC)

It presents in 4.2.4 too on MW 1.13 --ZoTyA 08:49, 27 August 2008 (UTC)

I'm not getting any errors or warnings on 1.13, could you let me know the details of your errors? --Nad 10:40, 27 August 2008 (UTC)

Same errors as above (expect in line #410)

preg-replace-callback error (resolved)

This is a new installation

• MediaWiki: 1.13.0
• PHP: 5.2.0-8+etch11 (cgi-fcgi)
• MySQL: 5.0.32-Debian_7etch6-log

$wgSecurityUseDBHook=true;
require_once("$IP/extensions/SimpleSecurity/SimpleSecurity.php");
$wgSecurityRenderInfo=true;
$wgSecurityAllowUnreadableLinks=false;

If I log'd in as a user I got this:

Warning: preg_replace_callback() [function.preg-replace-callback]: Unable to call custom replacement function in /wiki/extensions/SimpleSecurity/SimpleSecurity.php(410) : eval()'d code on line 5

Uncommenting debug print in line #399. Got the warning in this SELECT (and lots other after this)

SELECT  *  FROM `tmwiki_user`  WHERE user_id = '1'  LIMIT 1  

If I not log'd in I got this:

Database error
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: 
SELECT rev_page FROM `tmwiki_revision` WHERE rev_text_id = LIMIT 1 
from within function "SimpleSecurity::validateRow". MySQL returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'LIMIT 1' at line 1 (localhost)".

What details do you need?

-- ZoTyA 11:29, 27 August 2008 (UTC)

Are you sure you're using SimpleSecurity version 4.2.4? the errors and line numbers you're reporting don't match the version. Check in your special:version page --Nad 12:50, 27 August 2008 (UTC)

It's "4.2.4, 2008-08-27" from trunk-r40071. Now I downloaded 4.2.5 (trunk-r40079), and the error still there!?! -- ZoTyA 16:26, 27 August 2008 (UTC)

Tried 4.2.7 from trunk-r40119 and no change :( I've google'd a few and I found a PHP bug witch seems to be present in the official Debian Etch PHP5 (5.2.0-8+etch11) package. I don't know what to do :( -- ZoTyA 10:06, 28 August 2008 (UTC)

I think the error is not that Etch/PHP bug, I think that your wiki is doing database activity earlier than mine (perhaps another extension does some early access) and that the database hook is trying to execute the SimpleSecurity::PatchSQL method before it has been defined. Just in case this is what's happening I've made the database hooks not execute if $wgSimpleSecurity is not an object, so try 4.2.8 and let me know if any luck --Nad 10:35, 28 August 2008 (UTC)

Same error with 4.2.8! If no other extension loaded I got the same error. if $wgSecurityUseDBHook=false; there are no errors and everything works fine (as I see) -- ZoTyA 11:12, 28 August 2008 (UTC)

Fixed in 2.4.9, 2008-08-30 -- ZoTyA 06:55, 30 August 2008 (UTC)

Category-based permissions don't work (resolved)

I Need to define a category which can only be edited by a particular group. I've done the following in LocalSettings.php:

#to create a group
$wgGroupPermissions['PuedeEditar']['read']=true;
#only members of 'PuedeEditar' can edit on category 'ProtegidoEscritura'
$wgPageRestrictions['Category:ProtegidoEscritura']['edit'] = 'PuedeEditar';

I've created an user in the group 'PuedeEditar' and other user not in this group and also a page with de category 'ProtegidoEscritura':

Category:ProtegidoEscritura

The two users can edit the page...

My configuration of Simple Security on LocalSettings is:

$wgSecurityUseDBHook=true;
$wgSecurityAllowUnreadableLinks=false;
$wgSecurityRenderInfo=true;

I use MediaWiki 1.13 and the last version of Simple Security (4.2.2)

¿ Any suggestions ?

What does the list of restrictions say in the security info on a page thats not working? --Nad 09:58, 26 August 2008 (UTC)

With $wgSecurityRenderInfo = true, there isn't any restrictions info in the page. It seems that the restriction is not being applied. Anyway, when I protect the page using the tab, I can see the restriction information.

I've got a new 1.13 running to debug it in, I should be able to have it running soon --Nad 12:54, 26 August 2008 (UTC)

I've fixed some more bugs and got it working in 1.13, give it a try now with version 4.2.4. --Nad 07:51, 27 August 2008 (UTC)

Problem in my MW 1.13 (resolved)

The extention functions worked well.

But on the top of the site (over the logo) apears a text with all the rights of the user

Like this:

"Array ( [0] => userrights [1] => noratelimit [2] => usermerge [3]..."

How can I fix that?

Comment out the line #221 of SimpleSecurity.php

  # Put the anon read right back in $wgGroupPermissions if it was there initially
  # - it had to be removed because Title::userCanRead short-circuits with it
- print_r($rights);
+ #print_r($rights); 

-- ZoTyA 09:26, 28 August 2008 (UTC)

$wgSecurityExtraGroups in MW 1.13

I haven't used SimpleSecurity before MV 1.13. Is $wgSecurityExtraGroups fully working?

$wgSecurityExtraGroups = array(
    'foo' => 'Foo group',
    'bar' => 'Bar group'
);

The above example makes the protect tab's edit/move/read input select size +2 but the last two is empty (nothing rendered in the source).

$wgSecurityExtraGroups = array(
    'edit' => 'something',
);

If the index is edit/move/read that makes the protect tab's edit/move/read select size +1 and the last options name is something, value is edit (the index).

Ofcourse I tried to add groups witch have users and at least read right.

-- ZoTyA 17:22, 28 August 2008 (UTC)

Any comments? -- ZoTyA 17:26, 2 September 2008 (UTC)

The index should be the internal name of a group (as seen in the user rights special page etc), and the value is a more friendly name shown in the protection form. There should not be any actions specified in that array it's just for adding groups into the protection form. --Nad 22:30, 2 September 2008 (UTC)

Have you gotten this working? Because I'm experiencing the same blank space in the select box. I've specified the same name as a group I created, but it still only shows a blank. Jprice 18:19, 4 September 2008 (UTC)

No, it's still not working to me -- ZoTyA 19:01, 4 September 2008 (UTC)

Here's what I have in my LocalSettings.php:

$wgGroupPermissions['DBA' ]['move']            = true;
$wgGroupPermissions['DBA' ]['read']            = true;
$wgGroupPermissions['DBA' ]['edit']            = true;
$wgGroupPermissions['DBA' ]['createpage']      = true;

# Security
$wgSecurityUseDBHook = true;
include("$IP/extensions/SimpleSecurity/SimpleSecurity.php");
$wgSecurityExtraGroups = array('DBA' => 'DBA group');

Still only getting an extra blank space in the selection box right below 'Sysops only'. What am I missing? Jprice 13:22, 5 September 2008 (UTC)

You're right it's not working in 1.13, I'll look in to it shortly --Nad 22:31, 5 September 2008 (UTC)

Ok try it now, I found what 1.13 was doing differently and accounted for it --Nad 01:00, 6 September 2008 (UTC)

It's working for me -- ZoTyA 09:22, 7 September 2008 (UTC)

Still not for me. Since it works for ZoTyA now, I can only assume it's something wrong in my setup. Is there any way to turn on any debugging to see what it's doing? -- Jprice 12:33, 8 September 2008 (UTC)

Figured it out. It's a problem with Firefox 3. It works fine now in IE. Not sure what FF is doing differently, but I've had a few issues with FF3. Seriously considering downgrading back to v2. -- Jprice 15:08, 8 September 2008 (UTC)

Strange because I use FF3 too. -- ZoTyA 18:06, 8 September 2008 (UTC)

I'm on FF3 too with no problem, is this still the problem of the extra group not showing or something else? --Nad 21:19, 8 September 2008 (UTC)

Strange. Yes, it's the same "blank space" issue. Can't imagine it's anything in my LocalSettings.php, since it works in IE. Is there some obscure browser setting that would cause this? -- Jprice 21:30, 8 September 2008 (UTC)

I'm not sure it's a strange one alright, could you give me the html source of the FF3 page? probly best to email it to me on aran at organicdesign dot co dot nz. --Nad 00:25, 9 September 2008 (UTC)

Just emailed the info. I'm wondering if this could be some sort of cache issue? Clearing the browser cache didn't help. Is there some way to clear out the MW cache? -- Jprice 13:18, 9 September 2008 (UTC)

You can clear the cache in MediaWiki by adding action=purge to the query string. It behaves differently depending on whether you are an anonymous login or not --Zven 21:56, 10 September 2008 (UTC)

I had another extension act a little whacky on me. That plus some performance issues with FF3 was the last straw. I've downgraded back to FF2, and it's working fine. If you happen to find out why it wasn't working, I'd be curious to know. But I'm going to wait a few months before trying FF3 again. -- Jprice 19:23, 9 September 2008 (UTC)

I have the same problem. I tryed it in Firefox 2 and Internet Explorer 7 but get still blank spaces. I also cleared the browser cache aswell as the MediaWiki cache but no effect. Im using MediaWiki 1.13.1 and have PHP 5.2.4-2 installed. --Cagey83 13:33, 18 September 2008 (UTC)

Ok, I thought it was resolved, but it's back. Maybe I didn't check closely enough last time, but it's the "blank space" issue again. What I've found is quite strange. If I'm logged in as any user (even wikiadmin) I just get the extra blank space in the box. If I log out, and then click on the back button(to get back to the protect page), and refresh, then the group appears! Although it's greyed out because non-logged in users do not have the 'protect' privilege. If I log back in and refresh, the group disappears and is replaced with the blank space. -- Jprice 20:41, 18 September 2008 (UTC)

It's seems like it's something with the protect priv. Once I set

$wgGroupPermissions['user']['protect'] = false;

then refreshed the page as a logged in user, I can see the extra groups. (greyed out of course) So why can't I see them when the protect priv is set to true? -- Jprice 20:49, 18 September 2008 (UTC)

I'm having the exact same issue as Jprice, running a fresh install of 1.13.1 --GravitySpec 07:29, 19 September 2008 (UTC)

It's the same for me aswell as Jprice described it. --Cagey83 16:09, 19 September 2008 (UTC)

Well, I've been playing around with this quite a bit, and I'm finally getting somewhere. I started rearranging the order of things in LocalSettings.php. This is what the relevant section of the file looks like now:

# Create additional groups
$wgGroupPermissions['MGR']['read'] = true;
$wgGroupPermissions['ORA']['read'] = true;
$wgGroupPermissions['SQL']['read'] = true;
$wgGroupPermissions['DB2']['read'] = true;

# Security
$wgSecurityUseDBHook = true;
include("$IP/extensions/SimpleSecurity/SimpleSecurity.php");
$wgSecurityExtraGroups = array( 'MGR' => 'Managers',
                                'ORA' => 'Oracle DBAs',
                                'SQL' => 'SQL Server DBAs',
                                'DB2' => 'DB2 DBAs');

I then assigned certain groups to different users in the "User rights management" page. Now users can only see the groups to which they belong. Then rest of the spots are still blank. Which really isn't a problem, since I can't see why a user would want to protect a page to a group outside of what they are assigned.

Because of this, I specifically assigned all the groups to the wikiadmin user, so all of them are visible when logged in as wikiadmin. -- Jprice 17:00, 19 September 2008 (UTC)

Thanks for the great discovery Jprice! I added my admin user that I created to the group I created and it became visible too. Working like a charm now! :D --GravitySpec 22:08, 19 September 2008 (UTC)

Ohhh, I searched so long. But thx for your conclusion, I added it OK? VanGore 21:27, 9 October 2008 (UTC)

JPrice-You are rocking!!!!- Prakash Barathan.

not an action group permission (resolved)

Some extensions expects that the group permission's name does not contains space. I don't know what is the MW rule for this, but can you change it to not_an_action ?

SimpleSecurity.php line #109.

foreach ($wgSecurityExtraGroups as $k => $v) {
   if (empty($v)) $v = ucfirst($k);
   $wgRestrictionLevels[] = $k;
   $wgMessageCache->addMessages(array( "protect-level-$k" => $v ));
   #$wgGroupPermissions[$k]['not an action'] = true; # Ensure the new groups show up in rights management
   $wgGroupPermissions[$k]['not_an_action'] = true; # Ensure the new groups show up in rights management
}

-- ZoTyA 17:53, 28 August 2008 (UTC)

Ok done. Do you have your wiki available online so I can have a look and see if I can see why your DBHook won't work? --Nad 20:28, 28 August 2008 (UTC)

It's one of my client's and it's available online but its already contains a lot of private information, so I can't give you access to it. neither an account nor ftp access. But if you tell me what to debug/see it would be my pleasure. -- ZoTyA 12:58, 29 August 2008 (UTC)

Looks like I found the problem :-) it says in the PHP docs (here) that specifying a callback function which is a static method using the "class::method" format requires PHP>5.2.3, so I've changed it to array("class","method") which should work for all PHP5.x. Try the latest version and see if you're still getting the error. --Nad 22:52, 29 August 2008 (UTC)

I tested the situation on a PHP 5.2.0 set up and got the same error as you, the latest SimpleSecurity version doesn't have the error! --Nad 03:49, 30 August 2008 (UTC)

Looks good! No preg_replace_callback warning and no sql error! -- ZoTyA 06:54, 30 August 2008 (UTC)

Fatal error in MW 1.13

It doesn't happen often, but I'm sometimes getting this:

Fatal error: Call to a member function userCanReadTitle() on a non-object in /var/lib/mediawiki1.7/extensions/SimpleSecurity/SimpleSecurity.php on line 278

It seems to be when I haven't been to the wiki in a while (say a day). The only way I can clear it up is to comment out the extension from LocalSettings.php, refresh the page, then uncomment it. Then it works. ...at least for a while. (btw, I realize the path shows 1.7, but I upgraded to 1.13) Jprice 18:13, 4 September 2008 (UTC)

It happened absolutely the same to me today. I think it's about the MW cache. -- ZoTyA 19:00, 4 September 2008 (UTC)

My cache is set as $wgMainCacheType = CACHE_NONE; Should it be set to something else? Jprice 19:17, 4 September 2008 (UTC)

That's weird, that function should only get called on the condition that the object exists, try the latest version, I've changed it slightly which even if it still has a problem may shed more light on it. --Nad 20:58, 4 September 2008 (UTC)

SimpleSecurity cause search to fail (resolved)

hey Aran,

I noticed a big bug... The search function doesn't work when simplesecurity is active. It returns nothing. I'm running mw 1.11.

and can you choose multiple groups in the per page protection? I know you can add multiple groups in category protection.

thanks.

m

in <1.13 search returns no results, in 1.13+ causes an error SearchEngineDummy::replacePrefixes() method not found --Nad 01:32, 6 September 2008 (UTC)

Fixed, searchEngine type is based on DBType --Nad 21:19, 6 September 2008 (UTC)

conflict with parserfunctions (resolved)

ParserFunctions are works well before apply this SimpleSecurity extention.
But it doesn't work after applied SimpleSecurity extention.
{{#if:{{#ifexpr:{{{1}}}}}|{{{1}}}|{{#expr: .........
Could you check if any conflict with parserfunctions?

MediaWiki: 1.12.0
PHP: 5.2.5
MySQL: 5.0.51a
extentions: Inputbox, ParserFunctions(1.1.1), SimpleSecurity(4.2.13, 2008-09-07)

thanks --203.247.149.205 04:44, 8 September 2008 (UTC)

I'm not seeing any problem with ParserFunctions and SimpleSecurity, could you give me more details on how it's failing exactly, and ensure that it's definitely only failing while SimpleSecurity is also installed? --Nad 10:55, 8 September 2008 (UTC)

I found out ParserFunction was wrong only after SimpleSecurity installed. So, I tried comment out 'including SimpleSecurity'.

//include('extensions/SimpleSecurity/SimpleSecurity.php'); --> parserFunction works well.

include('extensions/SimpleSecurity/SimpleSecurity.php'); --> parserFunction doesn't works.

Could you let me know which part show you?
Thank you very much, Nad!! --203.247.149.205 00:42, 9 September 2008 (UTC)

I solved this problem.
My problem cleared by installing 'LOParserFunctions' extentions. That is, my problem has no connection with SimpleSecurity.
Thanks for your attention! --203.247.149.205 06:29, 9 September 2008 (UTC)

New User: Had similar problem with parser function not working after I installed Simple Security 4.2.15 yesterday and using MW 1.12. (PHP 5.2.6, MySQL 4.1.20) I believe there is an order dependency and can be fixed by using array_push($wgExtensionFunctions, 'wfSetupSimpleSecurity'); instead of array_unshift. It appears to be working, but I don't know what other effects this has. --12.14.171.34 17:00, 26 February 2009 (UTC)

Two (now three) problems

Hi, I'm using SimpleSecurity Version 4.1.2 and have three problems with it:

1. The category-based permissions doesn't work. I like to restrict read and edit access to the category "Management" to the group "bureaucrat". So I added $wgPageRestrictions['Category:Management']['read'] = 'bureaucrat'; to my LocalSettings.php. But nothing happens. Since I use a german MediaWiki installation I also tried $wgPageRestrictions['Kategorie:Management']['read'] = 'bureaucrat'; but that doesn't help neither.
2. When I protect a single page that works in principle. But Sysops are able to watch pages that should be only visible for bureauctats. Edit restriction works properly anyway.
3. When I restrict the read access to a single page only for bureaucrats, normal users can't see them actually. But instead of an error message or something they get a "The page can not be displayed" error screen by the browser.

--JazzmanDE 14:46, 12 September 2008 (UTC)

First upgrade SimpleSecurity to the latest version, there have been many changes since 4.1.2, second let me know your MW version and if possible a link to the site so I can check it out. --Nad 21:13, 12 September 2008 (UTC)

I'm afraid but I can't upgrade SimpleSecurity because ParserFunctions doesn't seem to work properly with the current version. When I use 4.2.14 some more complex code doesn'T work anymore. --JazzmanDE 10:30, 17 September 2008 (UTC)

P.S. The usage of Extension:LO Parser Functions avoids some errors but not all of them. I can't say what's exaclty not working but with SimpleSecurity 4.1.2. I hadn't this problem. --JazzmanDE 11:55, 17 September 2008 (UTC)

P.P.S. With 4.2.14 the category-based permissions seem to work in general. But nothing really happens, just a <security info> appears on the pages in the category. --JazzmanDE 12:03, 17 September 2008 (UTC)

P.P.P.S. My MW version is 1.12.0 but sadly I can't give you access to the contents of the wiki. --JazzmanDE 14:24, 17 September 2008 (UTC)

I can't be much help if you can't tell me exactly what's not working, and I need to know what's failing with the latest version, not in 4.1.2. I have it running on 1.12 and 1.13 with parser functions and have no problems, so I need to specifically what's failing to test it. --Nad 20:19, 17 September 2008 (UTC)

Alright, I'll try to describe it more precisely:

• Frame data:

• MediaWiki Version 1.12.0
• PHP 5.2.6
• MySQL 4.1.22
• Additional extensions: CSS 1.0.4, DynamicPageList2 1.7.4, Inputbox (no version displayed), Sort2
• Aim: To allow only bureaucrats to read, edit or move pages in the category "Management" (neither admins)
• Configuration code in LocalSettings.php:

$wgPageRestrictions['Category:Management']['read'] = 'bureaucrat';
$wgPageRestrictions['Category:Management']['edit'] = 'bureaucrat';
$wgPageRestrictions['Category:Management']['move'] = 'bureaucrat';

• Case 1: ParserFunctions 1.1.1, SimpleSecurity 4.1.2

• Admins: Can view, edit and move pages in the category.
• Normal users: Can't view, "Page can't be displayed" browser error when trying to reach page directly.

• Case 2: ParserFunctions 1.1.1, SimpleSecurity 4.2.14

• Admins: Can view, edit and move pages in the category. Text "<security-info>" is displayed on top of the page.
• Normal users: Cant't view the page, correct error messages from wiki.
• Bureaucrats: Can view/edit neither.
• Parser errors: Obviously #expr, #ifeq and #switch functions doesn't seem to work.

• Case 3: LO Parser Functions, SimpleSecurity 4.2.14

• Admins/users/bureaucrats:Same as Case 2.
• Parser errors: #expr works, #switch and #ifeq don't.

I hope the problem is clearer now. Thanks for your effort! --JazzmanDE 11:15, 18 September 2008 (UTC)

P.S. Case 3 seems to be a problem with LO Parser Functions (didn't have a closer look on that extension yet). The problem remains when disabling SimpleSecurity. --JazzmanDE 11:29, 18 September 2008 (UTC)

Extra security groups won't show up

I added your sample extra security groups to $wgSecurityExtraGroups but they won't show up. Strangely enough the html select box property "size" has the right number of entries, but no extra option rows are added. So my list has empty entries. Im using MediaWiki 1.13.1 and have PHP 5.2.4-2 installed. --Cagey83 13:08, 18 September 2008 (UTC)

Okay, it's the same as Problem 7--Cagey83 13:19, 18 September 2008 (UTC)

Security-based conditions and Redirects

Is it possible to use redirects with the security based conditional content? I'm trying the following:

{{#ifgroup:user
|
[[link 1]]
[[link 2]]
[[link 3]]
|
#REDIRECT [[Another page]]
}}

Unfortunately this just renders the actual text for anonymous users:

1. REDIRECT Another page

Maybe this is just my lack of understanding on exactly how the redirects work behind the scenes. But is it possible to make this work? -- Jprice 14:06, 24 September 2008 (UTC)

I don't know about that, its an issue concerning parser-functions/templates in general so you'd probably want to test results on a few versions of mediawiki. --Nad 01:02, 2 October 2008 (UTC)

Tables not Working Correctly

I tried putting in some tables but they arent working. Here is one of my pages:

[[Category : Main]]
{{#ifgroup:sysop
| SysOp User 
}}

{{#ifgroup:dod
| DOD User
{| cellpadding="20" cellspacing="0" border="1"
|Orange
|Apple
|-
|Bread
|Pie
|-
|Butter
|Ice cream 
|}
}}

This is what appears for a user that is part of both the sysop and dod groups.

SysOp User


cellpadding="20" cellspacing="0" border="1" 

Is there something i missed? Here is my Localhost settings:

$wgGroupPermissions['dod']['read']            = true;
$wgGroupPermissions['dod']['edit']            = false;
$wgGroupPermissions['dod']['createpage']      = false;
$wgGroupPermissions['dod']['move']            = false;

$wgSecurityExtraGroups = array(
    'dod' => 'DOD',
    'premise' => 'Premise'
);

$wgPageRestrictions['Category:Main']['read'] = array('dod', 'premise', 'sysops');

I'm using MW 1.11, PHP5, MySQL 5. Hope you can help me out here! Thanks!!

SellFone 11:29, 25 September 2008 (UTC)

You can't embed wikitext tables inside parser-functions because the pipe symbols are treated as parameter separaters, you can either use HTML syntax for you table, or create a template to contain the pipe symbol, see Category:Workaround templates. --Nad 21:22, 25 September 2008 (UTC)

Thanks Nad! You might want to put that in the main discussion page that might help out other people. If i have time ill research on how to setup a template. SellFone 04:53, 26 September 2008 (UTC)

It doesn't really belong here as it's not related to this extension, it's to do with the MediaWiki parser and parser-functions in general. --Nad 19:57, 26 September 2008 (UTC)

Me again

Hi, that's the one with the three problems again ;) I tried the new SimpleSecurity version and don't have any problems with ParserFunctions anymore. Sadly SimpleSecurity doesn't really work yet. Instead of protecting a page in a "forbidden" category my wiki displays a "<security-info"> on top of the content section.

An interesting detail which possibly might help you is that the following text appears when I try to copy+paste the "<security-info>":

<security-info>
<security-inforestrict> <security-desc-LS> 
<security-inforestrict> <security-desc-LS> 
<security-inforestrict> <security-desc-LS> 
<security-inforestrict> <security-desc-PR> 
<security-infosysops> 

--JazzmanDE 12:43, 1 October 2008 (UTC)

Sorry, I didn't describe the problem correctly: Admins and normal users shouldn't be allowed to read the pages. Bureaucrats shoud be. But bureaucrats and normal users can't, admins can. That's my LocalSettings code:

$wgSecurityUseDBHook = true;
include("$IP/extensions/SimpleSecurity/SimpleSecurity.php");

$wgPageRestrictions['Category:Management']['read'] = 'bureaucrat';
$wgPageRestrictions['Category:Management']['edit'] = 'bureaucrat';
$wgPageRestrictions['Category:Management']['move'] = 'bureaucrat';
$wgSecurityExtraGroups = array ('bureaucrat' => 'Management'); 

--JazzmanDE 12:50, 1 October 2008 (UTC)

Ok, I made some progress: The "<security-info>" disappeared after setting $wgSecurityRenderInfo = false;. Bureaucrats couldn't access the pages because they were individually protected for some reason. The last problem now is that admins can read pages they shoudln't. I also have that "blank rows in protection menu" problem but that's not important since I only want to use the category-based options. --JazzmanDE 13:26, 1 October 2008 (UTC)

Those tag-looking problems happen when the system messages aren't being defined, I think this is because your default language is not english so the messages are being defined. I'll change it to make the english ones default in the case of non-english wiki's. --Nad 22:03, 1 October 2008 (UTC)

Ok, thanks. Do you have a hint relating to the admin rights problem? Is it normal that admins can read pages they shoudn't be allowed to according to the SimpleAccess preferences? --JazzmanDE 14:19, 7 October 2008 (UTC)

The sysop group bypasses security and can do anything, usually bureaucrats are also sysops but have the additional power to create other sysops. --Nad 19:24, 7 October 2008 (UTC)

I see. Ok, now I use only custom groups instead of the predefined MW groups and there aren't any problems anymore. Thanks again! --JazzmanDE 10:21, 8 October 2008 (UTC)

Cannot redeclare wfsimplesecuritydbhook()

I'm getting this error when I try to click onto Special:Specialpages:

Fatal error: Cannot redeclare wfsimplesecuritydbhook() (previously declared in D:\WebSites\[path hidden]\extensions\SimpleSecurity\SimpleSecurity.php:416) in D:\WebSites\[path hidden]\extensions\SimpleSecurity\SimpleSecurity.php on line 436

It still happens with the db hook disabled. Versions:

• SimpleSecurity (version 4.2.14, 2008-09-12)
• MediaWiki: 1.11.0
• PHP: 5.2.3 (isapi)
• MySQL: 5.0.41-community-nt

Any suggestions? - Borofkin 03:51, 15 October 2008 (UTC)

I can't see any way for that error to occur unless you're including the script twice somehow? --Nad 21:10, 17 October 2008 (UTC)

I was getting this error on MediaWiki 1.13.5 and SimpleSecurity-r44539. I eventually fixed it by disabling the Bibwiki extension. The error was occuring on any page that had bibwiki referenes. - Borofkin 01:48, 27 March 2009 (UTC)

A quick answer

Zhentg 06:24, 22 June 2009 (UTC)

I met this error when I installed Bibwiki after SimpleSecurity. I found the error is caused by a setting statement in the LocalSettings.php. The statement is "include("extensions/SimpleSecurity/SimpleSecurity.php")", and when modified to "require_once("extensions/SimpleSecurity/SimpleSecurity.php");", the error will not exsists. Why the error happened after the installation of Bibwiki? Because inside the file BibwikiSettings.php of Bibwiki, there is a statement "include("LocalSettings.php")", with which PHP engine will declare wfsimplesecuritydbhook() twice if we use "include("extensions/SimpleSecurity/SimpleSecurity.php")" in the LocalSettings.php.

Breaks CategoryCloud extension?

This appears to break the extension CategoryCloud (running MW 1.12): Extension:CategoryCloud

Anybody know why this would occur?

Hmm, just upgraded to MW 1.13.2 and now it gives an error instead of nothing at all:

Warning: Cannot modify header information - headers already sent by (output started at /var/www/wiki/extensions/CategoryCloud.php:247) in /var/www/wiki/includes/WebResponse.php on line 10

Another question I have is whether SimpleSecurity modifies the MW database at all. Does it store the new "Protect" tab read security in the database somewhere?

Thanks! -Ben

A warning must have been outputted to raise the header message - can you see a warning message anywhere? maybe look in the page source. Regarding the second question, SimpleSecurity just extends the inherent MW protection so does not need to modify the database content in any way. --Nad 20:03, 13 December 2008 (UTC)

SphinxSearch Extension

Hi, just wondering if there's any way to integrate this with Extension:SphinxSearch - it currently displays text of pages in search results regardless of the permissions. If anyone has any suggestions on better search engines, any help is appreciated.

Cheers, Dave --137.166.16.170 04:17, 30 October 2008 (UTC)

It shouldn't be possible for protected text to be read if you have $wgSecurityUseDBHook set to true --Nad 19:58, 13 December 2008 (UTC)

Hi, I have

$wgSecurityUseDBHook=true;

include("$IP/extensions/SimpleSecurity/SimpleSecurity.php");

And Sphinx Search display text of the articles to users without permissions. I have Media Wiki 1.13.2 And Simple Security 4.2.14

I've updated to Versión 4.2.15 and still not working.

Solution

The problem is (at least in my understanding) that Sphinx has its own DB access so this extension which is intercepting the MW DB access won't be used for SphinxSearch.

There is a "solution" listed at the SphinxSearch extension talk page (using $title->userCanRead modification in SphinxSearch_body.php) but that did not work for me. After hours of tinkering (have php experience, but mediawiki is scary) I made it finally work, you need to use $title_obj->userCan('read'). Look for the following code in extensions/SphinxSearch/SphinxSearch_body.php (function wfSphinxDisplayResults, in SphinxSearch extension version r82192 it is line 484):

                               if ( $page_content ) {
                                       $title_obj = Title::newFromID( $doc );
                                       if ( is_object( $title_obj ) ) {
                                               $wiki_title = $title_obj->getPrefixedText();
                                               $wiki_path = $title_obj->getPrefixedDBkey();

and replace the if( is_object($title_obj)) { line with:

                                       if ( is_object( $title_obj )  && $title_obj->userCan('read')===true) {

I am running this combination:

• Mediawiki 1.16.2
• SimpleSecurity (Version 4.5.1, 2010-10-16)
• SphinxSearch (Version 0.7.2)

Hope this helps somebody else -- 193.24.32.39 15:43, 24 February 2011 (UTC)

Who has access to the new SimpleSecurity protect tab

Actually, I would like to know how can I provide users with the protect tab overrided by SimpleSecurity. Right now, only WikiSysop has this nice facility.

Thanks for any advice Daniel

MW 1.13 AJAX search suggestions only work for logged in users

It appears that the AJAX search suggestions feature of MW 1.13 only works for logged in users. It works with all users if I disable SimpleSecurity. I would like it to work whether logged in or not. Is this a bug, or do I need to specify some kind of setting to allow this?

Thanks!

I'll second that. I see the same behavior. --Member005 17:18, 26 November 2008 (UTC)

Thats a bug, I'll have to look in to that when I gets some time next --Nad 19:56, 13 December 2008 (UTC)

Is there any more news on this bug, or should I try the newest version? Thanks for the help! -Ben

Just tried the latest version and this still doesn't work... Please help. 5 June 2009

1.13.2 and rebuildtextindex.php

Hi

I get this error when I reindex the index manually:

[ bash ]: php rebuildtextindex.php
Rebuilding index fields for 1161 pages...
	0A database query syntax error has occurred.
The last attempted database query was:
"SELECT  rev_page  FROM `revision`  WHERE rev_text_id =   LIMIT 1  "
from within function "SimpleSecurity::validateRow".
MySQL returned error "1064: You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near 'LIMIT 1' at line 1 (localhost)"

What can I do? I hope the automatic index is done ...

Cheers

André

Try the latest version (4.2.15), it shouldn't fail under those conditions now. --Nad 19:53, 13 December 2008 (UTC)

Category to group restriction can only set as "AND" logic but not "OR"?

That is, if I use

$wgPageRestrictions['cat1']['read'] = 'g1';
$wgPageRestrictions['cat2']['read'] = 'g2';

and set "article1" belongs to both 'cat1' and 'cat2', it will cause users only belong to 'g1' or users only belong to 'g2' DONOT have read right on "article1", and only users belong to 'g1' and 'g2' simultaneously have read permission. And it's a strict perm restriction.

Could you use an option to let user select to use a looser restriction: users of 'g1' or users of 'g2' both have permission?

Thank you!

-Keyn

--QuixotiCfluX 14:13, 14 May 2009 (UTC) I am having this same issue, I have a restricted namespace, but I want to allow a couple pages to be viewable to other users, I set the controls in the protect tab to keep moving restricted to the group, but allow viewing by autoconfirmed users: here is what the security message on the page shows:

read is restricted to the Licensing group (applies because this article is in the 100 namespace) 
move is restricted to the Licensing group (set from the protect tab) 
read is restricted to the autoconfirmed group (set from the protect tab) 
No restrictions are in effect because you are a member of the sysop group 

Is it even possible to allow a page to be accessed by someone who does not belong to the group the namespace is restricted to?

I'm going to be looking into the code of this extension to see if I can provide any assistance. --QuixotiCfluX 14:13, 14 May 2009 (UTC)

what is $wgSecurityAllowUser for?

I saw this, and am trying to figure out how to allow for specific users (vs just groups) to be able to be selected on the pages... I see this:

 $wgSecurityAllowUser            = false;                        # Allow restrictions based on user not just group

but I can't find where that's used anywhere. Is this on the roadmap? Anything I could help w/?

--Bretm 22:24, 12 December 2008 (UTC)

That's for a feature which has not been implemented yet for setting protection based on individual users rather than just by group as it currently is. --Nad 19:41, 13 December 2008 (UTC)

Namespace restriction protects whole wiki

I'd like to read-protect a specific namespace "VT1".

After adding the following line to my LocalSettings.php, the entire wiki gets read-protected for all users except "students".

$wgPageRestrictions['Namespace:VT1']['read'] = 'student';

Category-based restriction works fine.

• MediaWiki version: 1.13.1
• SimpleSecurity version: 4.2.15
• Example (test wiki, german): http://gol.kilu.de/MediaWiki/

Would be great if you could help me there. --SG 11:16, 21 December 2008 (UTC)

I'm getting this same problem. I'm trying to protect a Custom Namespace as well and the entire wiki gets protected. When I look at the restrictions for a page in the Main namespace it tells me that it is protected because it is in the restricted namespace. If I protect two different custom namespaces the restrictions for all pages tell me they are protected because they are in both restricted custom namespaces. Let me know if there's any further information I can give. Jcrandall 19:48, 20 April 2009 (UTC)

I was having this same problem, but I think I've solved it by using the numerical id of the namespace --QuixotiCfluX 17:22, 13 May 2009 (UTC)

$wgGroupPermissions['BARUSERS'] = $wgGroupPermissions['sysop'];
...
define("NS_FOO", 100);//even numbers for the namespace
define("NS_FOO_TALK", 101);//odd numbers for the talk pages
$wgExtraNamespaces[NS_FOO] = "FooName";
$wgExtraNamespaces[NS_FOO_TALK] = "FooName_talk";
$wgContentNamespaces[] = NS_FOO;
##### ##### Simple Security
$wgSecurityUseDBHook = true; # this directive MUST be used before the extension include
require('extensions/SimpleSecurity/SimpleSecurity.php');
$wgSecurityRenderInfo = false; //display the security restrictions box
$wgSecurityAllowUnreadableLinks = false;//prevents users from being able to click on links they are not authorized to view
$wgSecurityExtraGroups = Array(
	'BARUSERS' => 'Foo Group'
);

Instead of

$wgPageRestrictions['Namespace:FooName']['read'] = 'BARUSER';

I used the ID of the namespace, and this seems to work

$wgPageRestrictions['Namespace:'.FOO]['read'] = 'BARUSER';

Hopefully this will help others--QuixotiCfluX 17:22, 13 May 2009 (UTC)

This bug has been fixed so that namespace names are used as shown in the docs rather than requiring the NS constants --Nad 09:09, 18 May 2009 (UTC)

ifgroup parser function doesn't work with user defined groups

I've added an extra group in $wgSecurityExtraGroups and made a test user a member of that group, but conditional content won't show up for that user. It works great for sysop though.

Here is the wiki code I am typically using...

{{#ifgroup:sysop,VanguardConsult|
==Hidden Subsections==
|}}
{{#ifgroup:VanguardConsult,sysop|*[[{{PAGENAME}}/Consult|Consultants]]|}}

In this case, 'VanguardConsult' has been added to $wgSecurityExtraGroups in LocalSettings. A test user that is a member of VanguardConsult cannot see any of the conditional stuff, while sysops can.

I'm using MW 1.13.2, ParserFunctions 1.1.1, and SimpleSecurity 4.2.15

Is there something I am missing? -Wezelboy

Try the latest version (4.3.3), some bugs to do with groups have recently been fixed. --Nad 09:07, 18 May 2009 (UTC)

ugly message on every page

After installing SimpleSecurity I am now getting a "There are security restrictions on this article" line at the top of every page. I have the wiki set so that only registered users can edit/move any pages and there is only one page that I want to be off limits to unregistered users. Any suggestions on how to get rid of this line? - Pat

Did you try setting $wgSecurityRenderInfo to false in your LocalSettings.php? -Wezelboy

Also you can make the message more subtle using CSS, see the documentation for example rules. --Nad 09:05, 18 May 2009 (UTC)

After install SimpleSecurity I can't login

After install SimpleSecurity I can't login or see any article. If I try to login I got an error message sayin "There is no user by the name..." and if I try to see the Main Page I got a message sayin: "There is currently no text in this page..." I don't know if it is a problem on my server or some configuration that I made incorrectly. I removed SimpleSecurity but the problem persists. I checked my Mysql and it is working. All articles are in the database.

If the problem exists even without SimpleSecurity installed it must be another extension, try removing them all and putting them back one by one to see which causes the problem. --Nad 09:05, 18 May 2009 (UTC)

permissions don't take an effect in mediawiki 1.14.0

Hi, In my mediawiki 1.14.0, I have SimpleSecurity setup as following:

$wgSecurityUseDBHook = true;
require_once( 'extensions/SimpleSecurity/SimpleSecurity.php' );
$wgSecurityRenderInfo = true;
$wgSecurityAllowUnreadableLinks = false;
$wgSecurityExtraGroups = array(
        'Epi' => 'Epithelial model group'
);

$wgGroupPermissions['Epi'] = $wgGroupPermissions['readOnly'];

$wgPageRestrictions['Category:Epithelial']['edit'] = 'Epi';

So in this setup, all pages should be editable for all users in the Epi group, however they're not. I get the restriction's notification on the right pages, but the user that's in this group can still only read, not edit the page.

Any suggestions?

Thanks in advance!

Tom

The assignment of $wgGroupPermissions['Epi'] to $wgGroupPermissions['readOnly'] doesn't make sense to me, what is $wgGroupPermissions['readOnly']? also that entry will be overwritten by SimpleSecurity since it will set $wgGroupPermissions['Epi'] from its entry in $wgSecurityExtraGroups. Try making all the group keys lowercase, i.e. "epi" instead of "Epi", the latest version has enforced this because of problems with case-sensitivity. And finally try upgrading to the latest version as some bugs to do with groups have been fixed recently. --Nad 09:03, 18 May 2009 (UTC)

SimpleSecurity (50406) doesn't play well with ConfirmAccount

Extension:ConfirmAccount breaks SimpleSecurity. What appears to happen (which may well be wrong..) is that without ConfirmAccount, the first trip through the UserGetRights hook chain has $wgTitle set, and so $this->mRights is initialized with both mediawiki rights and SimpleSecurity rights. However when ConfirmAccount is used, the first trip through the UserGetRights hook chain has $wgTitle set to null. SimpleSecurity_body.php:onUerGetRights:168 short-circuits and returns true, partially setting up $this->mRights with just mediawiki rights. On subsequent calls where $wgTitle is now set properly, UserGetRights isn't invoked (User.php:getRights), so SimpleSecurity restrictions aren't picked up.

The hackaround I used was to include in User.php:getRights

function getRights() {
global $wg

if( $wgTitle == '' )
  return null;

which evades setting up $this->mRights until a real page is to be rendered. It seems to do the trick with my installation, but there's probably a better way to do it in SimpleSecurity, since Extension:ConfirmAccount breaks Extension:Editsubpages in a similarly nasty way, and a fix was produced for that extension using a different hook (I guess).

Mediawiki-1.13.3 / php-5.2.4 / mysql-5.0.67.

Thanks for the info, I'll look into it soon, definitely a solution must be found which doesn't involve a file hack. --Nad 08:57, 18 May 2009 (UTC)

Cannot redeclare wfsimplesecuritydbhook()

Fatal error: Cannot redeclare wfsimplesecuritydbhook() (previously declared  
in /home/davi/domains/davinia.nl/public_html/project/extensions/SimpleSecurity/SimpleSecurity.php:416) 
in /home/davi/domains/davinia.nl/public_html/project/extensions/SimpleSecurity/SimpleSecurity.php on line 436

I've got no other extentions running this wiki, it's a clean install of 1.14.0

Please help

addition to my localsettings.php:

$wgSecurityUseDBHook = true; # this directive MUST be used before the extension include

require('extensions/SimpleSecurity/SimpleSecurity.php');



$wgSecurityUseDBHook = true; # Add this to enable the experimental DB hook for stronger security

include("$IP/extensions/SimpleSecurity/SimpleSecurity.php");



$wgPageRestrictions['Category:Showcase']['edit'] = array('sysop', 'management');

The error message indicates that you're including the extension twice, do you have both the include and require in the LocalSettings? you should have only one of them. --Nad 08:40, 18 May 2009 (UTC)

Ok, but that's not really clear then is it? It says clearly in the instructions of the require part that: "This directive MUST be used before the extension include"! How can you put in one thing before another thing and not have them both there!? And which one should stay, the "require"-one or the "include"-one?

Author only protection?

Hi, Is there a way to make an Author-edit only protection? Meaning that a node can only be changed by it's original creator/writer and/or sysop/moderator?

Bug with case-sensitive user groups

I installed this extension so I could use the $ifgroup function, and I was wracking my brain to figure out why it was failing. Turns out that our wiki uses groupnames that are not always lowercase, and SimpleSecurity parses the $ifgroup groupnames through a strtolower before comparing, thus making it impossible ever to return "true". To address this for the wiki I am helping with, I ended up replacing line 131 of SimpleSecurity.php:

		$intersection = array_intersect( array_map( 'strtolower', split( ',', $groups ) ), $wgUser->getEffectiveGroups() );

with this:

		$intersection = array_intersect( split( ',', $groups ) , $wgUser->getEffectiveGroups() );

Of course, I suppose if you were really worried about users getting the case wrong, you could also run BOTH $groups and $wgUser->getEffectiveGroups() through the strtolower and that would work too. Anyway, in case anyone wonders why their case-sensitive group tests are returning false, here's a patch that will allow it to work.

203.124.76.178 17:04, 10 June 2009 (UTC) (actually my name's Joren but I don't remember my login on this wiki)

How to prevent autoconfirmed users from editing the "Main Page" and "Help" pages?

All the users on my wiki have to register for an account. Once they register, they become autoconfirmed users. By using the SimpleSecurity Extension, I am able to recreate groups and assign users to specific groups. I can limit editing, moving, and reading of group created pages by members of other groups.

The SimpleSecurity Extensions doesn't seem to protect the default system pages such as "Main Page", "Community Portal", "Current Events", "Recent Changes", "Random Page", and "Help" from being edited by autoconfirmed users.

The strange thing is that those pages say they are protected by the SimpleSecurity Extension, but they are not. Any confirmed user can edit those pages.

How do I configure protection on the default "Main Page" and "Help Page" so even autoconfirmed users have NO edit rights?
Thanks!
Satow 22:32, 16 June 2009 (UTC)

Protect them as a sysop. --Nemo bis 18:45, 29 June 2009 (UTC)

I believe the issue with Recent Changes is still a problem, however. I don't get a Protect tab for it, and protecting the entire Namespace seems to protect search as well. My goal is to hide Recent Changes from unauthorized users, while still allowing them to search.

Dynamic main page

Hi, is there anyway of creating dynamic content in a page based on security restrictions besides the parser-functions indicated? I want my users to see only the pages they have permissions in when they go to the main page. Thanks for your help--86.24.193.46 23:17, 16 June 2009 (UTC)

{{#ifgroup: .. }} not working with additional groups

Firstly, Hi there. Thanks for the great extension! I am having a problem though. Here is my setup:

$wgSecurityUseDBHook = true; # this directive MUST be used before the extension include
require('extensions/SimpleSecurity/SimpleSecurity.php');
 
# All other SimpleSecurity directives MUST be specified after the include or the defaults will override them.
$wgSecurityRenderInfo = true;
$wgSecurityAllowUnreadableLinks = false;

$wgSecurityExtraGroups = array(
    'Subscribers' => 'Subscribers group',
    'SiteOwner' => 'Site Owners group'
);

Now I have this set:

{{#ifgroup:Subscribers|[{{{Article_Link}}} Download Article]|[{{{Shop_Link}}} Buy this article]}}

The Subscribers group is showing up in the special pages and I have assigned users to it. However the members of the Subscribers group are seeing the Buy this article link instead of the desired Download Article link. If I change the condition to

{{#ifgroup:sysop|[{{{Article_Link}}} Download Article]|[{{{Shop_Link}}} Buy this article]}}

Then it works correctly for sysops. It seems that it is not picking up the Subscribers group. I expect I have missed a step!
I am using Mediawiki 1.15 and SimpleSecurity 4.3.3.

Any ideas? Many thanks! Mitchelln 10:02, 18 June 2009 (UTC)

Fixed. Problem the same as Joren's well spotted strtolower bug. Thanks Joren!

Mitchelln 15:12, 25 June 2009 (UTC)

Log page

Because there is the part that a part of an indication message is not displayed normally, I report it. By all appearance it seems not to be revised whether the following parts of a body.php file displaying a page of log are things by update.

$wgLogTypes[]                  = 'security';
$wgLogNames  ['security']      = 'securitylogpage';
$wgLogHeaders['security']      = 'securitylogpagetext';
$wgLogActions['security/deny'] = 'securitylogentry';

Correction as follows

$wgLogTypes[]                  = 'security';
$wgLogNames  ['security']      = 'security-logpage';
$wgLogHeaders['security']      = 'security-logpagetext';
$wgLogActions['security/deny'] = 'security-logentry';

I will report because it is thought that the correction is necessary though this log is not understood of what being recorded. --Fievarsty 11:13, 16 July 2009 (UTC)

Cascading Protection Fails to Work

Hello, I recently installed your newest extension download and everything works well except for the "Cascading Protection" option. I check that option and restrict view / edit / etc from anyone but administrators from viewing. Save and use my other browser to attempt to go to that link. (Not logged in) and it doesnt work. (That part works great), however I copied and pasted a link that is on the page to my test browser and it goes to the page directly. It seems that the feature does not work.

I also used the search feature to find another page which its link is located in the cascading protection area with admin only access, however it is not blocked from non logged in users as well. Is there something I am doing wrong or some step I skipped? --Hiloboys 14:54, 16 July 2009 (HST)

User in self defined group cannot edit a page

Thank you for your great extension!!

Wiki: 1.15.1
PHP: 5
MySQL: 5.0

I've created a group basis with the extension GroupPermissionsManager. In this group I can do all of any permissions. This extension writes a config file to the backend in which the Parameter $wgGroupPermissions is set to the permissions I've set in the special page of the extension GroupPermissionsManager.

When I protect a page only for the group basis then, the user who is in this self defined group, can change the protection but CANNOT edit the page because of permission denied.

If I change back the edit permission to sysop it will work fine again?!

Can you help me, please!!! Perhaps I must use mediawiki in my intranet and therefore it would be very nice to use this extension too in my mediawiki.

Thanks a lot!!!

Timotheus.elias 09:57, 21 July 2009 (UTC)

Bug issue with trunk 1.16a version

See bugzilla:19842. --almaghi 13:56, 22 July 2009 (UTC)

Bug in MW1.15?

Hi everyone. I get the next messages after I'm including the extension:

Warning: Parameter 1 to Language::getMagic() expected to be a reference, value given in D:\wamp\www\w\includes\StubObject.php on line 58

Warning: Parameter 1 to SimpleSecurity::onUserGetRights() expected to be a reference, value given in D:\wamp\www\w\includes\Hooks.php on line 117
Internal error

Detected bug in an extension! Hook SimpleSecurity::onUserGetRights failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

#0 D:\wamp\www\w\includes\User.php(1976): wfRunHooks('UserGetRights', Array)
#1 D:\wamp\www\w\includes\User.php(2125): User->getRights()
#2 D:\wamp\www\w\includes\Title.php(1523): User->isAllowed('read')
#3 D:\wamp\www\w\includes\Wiki.php(151): Title->userCanRead()
#4 D:\wamp\www\w\includes\Wiki.php(55): MediaWiki->preliminaryChecks(Object(Title), Object(OutputPage), Object(WebRequest))
#5 D:\wamp\www\w\index.php(116): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#6 {main}

My settings are:

MediaWiki 1.15.1
PHP 5.3.0 (apache2handler)
MySQL 5.1.36-community-log

--Gregra 21:25, 2 September 2009 (UTC)

Version 4.3.0, 2009-03-24 works incorrect

Lets say we want to protect the Special Namespace. So we say : $wgPageRestrictions['Namespace:Special']['read'] = 'user';

That seems to do the trick because http://www.example.org/Special:SpecialPages is protected.

BUT http://www.example.org/Special:SpecialPages/ is not!!! (notice the / on the end of the url)

I am using v4.3.5 (2009-08-08) with MediaWiki v1.14.0 and the Namespace protection did not work correctly. After changing the code getNsText() in the line 324 of SimpleSecurity_body.php it looks better :-) --Jostar 19:17, 4 February 2010 (UTC)

$deny = $data == $title->getNamespace();

MW 1.15

Hey guys!

I just tried to run the extension with media wiki 1.15 on 3 different pcs, each running with different instances of wikipedia but as almaghi already wrote, it's not possible to run the extension. I always get the same error messages (as already shown above)

Warning: Parameter 1 to Language::getMagic() expected to be a reference, value given in D:\wamp\www\w\includes\StubObject.php on line 58

Warning: Parameter 1 to SimpleSecurity::onUserGetRights() expected to be a reference, value given in D:\wamp\www\w\includes\Hooks.php on line 117
Internal error

Detected bug in an extension! Hook SimpleSecurity::onUserGetRights failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

#0 D:\wamp\www\w\includes\User.php(1976): wfRunHooks('UserGetRights', Array)
#1 D:\wamp\www\w\includes\User.php(2125): User->getRights()
#2 D:\wamp\www\w\includes\Title.php(1523): User->isAllowed('read')
#3 D:\wamp\www\w\includes\Wiki.php(151): Title->userCanRead()
#4 D:\wamp\www\w\includes\Wiki.php(55): MediaWiki->preliminaryChecks(Object(Title), Object(OutputPage), Object(WebRequest))
#5 D:\wamp\www\w\index.php(116): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#6 {main}

But I want to get this plugin running! Any suggestions what I could do? I already hat a look at the source, but cant figure out whats the problem according to this error messager >_> Someone already solved this problem? I need simple security because I want to run it with the TreeviewMenu^^

thx, steven

---

I've got the same problem as steven, any ideas? --141.214.17.5 20:18, 15 June 2010 (UTC)

---

I've got a similar problem. Everything's OK in the page, except that the fist warning is shown with it. I have MW 1.5.1, PHP 5.3.1, MySQL 5.1.41, SimpleSecurity 4.4.3, running on Windows. Alberto --83.60.160.195 16:32, 24 June 2010 (UTC)

Solved for me. It seems to be a problem with PHP5.3, as other extensions have it. As they say, changing on Languajes.php

 function getMagic( &$mw ) { 

for

 function getMagic( $mw ) { 

solves it.

Alberto

Security bug for files

MW 1.15.1

define( 'SIMPLESECURITY_VERSION', '4.3.5, 2009-08-08' );

Reading protected files.

SimpleSecurity seems a protected file. (bug)

Special pages.

http://www.XXXXXX.org/wiki/Special:FilePath

Enter the file name without the "File:" prefix.

ex) Put the file name XXXXXX.jpg.

Seems!

SimpleSecurity is bug.

현재 버그로 파일 보호시 주의가 요망 됩니다.

--MW_User

This is likely a MediaWiki issue

The MediaWiki default installation does not check user credentials before displaying files/images. This may be the cause of your issue described above.

Are the following lines in your LocalSettings.php?

$wgUploadPath = "$wgScriptPath/img_auth.php";
$wgUploadDirectory = "images";

If not, try adding them (of course, be sure to delete other lines that set the variables listed here). As I understand it, these lines require MediaWiki to check user credentials before displaying files/images. --Fungiblename 10:38, 28 September 2009 (UTC)

Bugzilla

Filed as bugzilla:25227. Nemo 17:20, 20 September 2010 (UTC)

MW 1.15.1 error

As another user above, I'm having issues trying to get this working under 1.15.1: When I include the line

require_once("$IP/extensions/SimpleSecurity/SimpleSecurity.php");

it returns the following screen:

Internal error

Detected bug in an extension! Hook SimpleSecurity::onUserGetRights failed to return a value; should return true to 
continue hook processing or false to abort.

Backtrace:

#0 C:\Inetpub\wwwroot\wiki\mediawiki\includes\User.php(1976): wfRunHooks('UserGetRights', Array)
#1 C:\Inetpub\wwwroot\wiki\mediawiki\includes\User.php(2125): User->getRights()
#2 C:\Inetpub\wwwroot\wiki\mediawiki\includes\Title.php(1523): User->isAllowed('read')
#3 C:\Inetpub\wwwroot\wiki\mediawiki\includes\Wiki.php(151): Title->userCanRead()
#4 C:\Inetpub\wwwroot\wiki\mediawiki\includes\Wiki.php(55): MediaWiki->preliminaryChecks(Object(Title), Object(OutputPage), Object(WebRequest))
#5 C:\Inetpub\wwwroot\wiki\mediawiki\index.php(116): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), 
Object(User), Object(WebRequest))
#6 {main}

Please help!

System info: MediaWiki 1.15.1 PHP 5.3.0 (apache2handler) MySQL 5.1.40-community

--66.192.63.2 14:03, 29 October 2009 (UTC)

Two questions

Question one: Concerning cascading protection for other groups than "admins only"

System info: MediaWiki 1.15.1 PHP 5.2.11 (apache2handler) MySQL 5.0.41

Is it possible to use cascading protection for other groups than administrators? I want to protect a category and all of its pages and sub categories. The admins should of course have access, but I want to restrict this area by only giving access to an exclusive group.

Question two: Hiding content listing in category

It seems like this extension only hides the text contents. When I protect a category I wish to restrict the total viewing for this category. When protected users without access may still see the contents in a category, like what pages and sub categories this category includes. Is it possible to make an easy hack to hide everything, not only the text in the category view?

--Marius, 30 October 2009

page in Child Category permissions don't work

I use Extension:SimpleSecurity 4.3.3 in MediaWiki 1.15.1

MediaWiki 1.15.1 PHP 5.2.6 (apache2handler) MySQL 5.1.30-community

Has been able to successfully limit Category .

But, the page in Child Category in this Category don't work.

please help....,thank you!

I've done the following in LocalSettings.php:

$wgGroupPermissions['*']['read'] = false; $wgGroupPermissions['*']['edit'] = false;

$wgGroupPermissions['ITDept']['read'] = true;

$wgWhitelistRead = array( "main page", "Special:Userlogin", "-", "MediaWiki:Monobook.css" );

$wgSecurityUseDBHook = true; require_once("{$IP}/extensions/SimpleSecurity/SimpleSecurity.php");

$wgSecurityRenderInfo = true; $wgSecurityAllowUnreadableLinks = false;

$wgPageRestrictions['Category:aaa']['read'] = 'ITDept'; $wgPageRestrictions['Category:aaa']['edit'] = 'ITDept';

Other User:

 HERE is the same with my Wiki! Can us fix this Nad please? Thanks.

Bug with $wgSecurityGroupsArticle setting?

I am attempting to use the $wgSecurityGroupsArticle option so that I can define new security groups by listing them in an article. Everything appears to be working ok but for some reason I can't add anyone to the new groups I've created via the article. The new groups appear in the Protect tabs of all my articles, and they appears as options under User Rights Management, but whenever I check the appropriate box in User Rights Management to add a user and hit Save, it doesn't take. I can't even add myself to any of the groups and I'm a sysop. I haven't been able to find much documentation on this feature; am I doing something wrong? I'm using MW 1.14 and the latest version of SimpleSecurity.

It looks like the newest version of SimpleSecurity (4.4.0) does not fix this problem, but I have been able to learn more about the bug. It appears as though the name chosen for a security group can cause problems. If you choose a group name that is too long or contains spaces (like "Project 234A Team" or something similar), you won't be able to assign users to that group. You can assign articles to the group via the appropriate Protect tab just fine, but trying to assign users to the group doesn't work (same problem as above). If the group name is short and doesn't contain spaces, however, then everything appears to work. What's interesting is how the spaces are treated by the system. It clearly recognizes them because if I create a group on the Security Groups Article with spaces, it will be listed in Protect tabs as 'Require "Project 234A Team" permission' whereas if I create a group with no spaces it will simply be listed as "project234ateam". Note that the standard method of creating groups and friendly names still works fine. Does anyone have any info about this bug? Or perhaps it's not a bug and I'm just not using the feature correctly? (128.135.74.179 16:04, 23 April 2010 (UTC))

Move security-info and security-info-toggle to below content?

As the header would imply, I'm looking for a simple way to move the security toggle down below the content. I've used "float: right" in the CSS to move the box to the right, which helps, but I'm looking for a way to make it a little less obtrusive. Is there an easy way to do that, short of modifying the extension PHP? Josp 15:52, 5 March 2010 (UTC)

PHP 5.3

Today my hosting company upgraded from PHP 5.2 to PHP 5.3, and that caused SimpleSecurity to stop working. I am running Mediawiki 1.15.1, and got the same error codes as has been reported here by at least two other persons:

Detected bug in an extension! Hook SimpleSecurity::onUserGetRights failed to return a value; should return true to continue hook processing or false to abort.
Backtrace:
#0 /customers/hugs.no/hugs.no/httpd.www/w/includes/User.php(1976): wfRunHooks('UserGetRights', Array)
#1 /customers/hugs.no/hugs.no/httpd.www/w/includes/User.php(2125): User->getRights()
#2 /customers/hugs.no/hugs.no/httpd.www/w/includes/Title.php(1523): User->isAllowed('read')
#3 /customers/hugs.no/hugs.no/httpd.www/w/includes/Wiki.php(151): Title->userCanRead()
#4 /customers/hugs.no/hugs.no/httpd.www/w/includes/Wiki.php(55): MediaWiki->preliminaryChecks(Object(Title), Object(OutputPage), Object(WebRequest))
#5 /customers/hugs.no/hugs.no/httpd.www/w/index.php(116): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#6 {main}

Anyone who can help?

Frihet 19:05, 8 March 2010 (UTC)

for the "Parameter 1 to SimpleSecurity::onUserGetRights() expected to be a reference, value given in..." error:

change ~line 169 of SimpleSecurity_body.php from:

public function onUserGetRights( &$user, &$rights ) {

to:

public function onUserGetRights( $user, $rights ) {

• added comments:
  • 1. Yes, this works.
  • 2. Are we sure that this change maintains the functionalities ?
  • 3. The line to change is now (may 2010) in file SimpleSecurity_body.php.
  • 4. And the development trunk does not integrate the correction...
• Comment again.
  • 1. Confirmed, this worked.

• Changed file name to correct one and new line number. Fix works for clearing error. Base security working. No elaborate testing. 04:40, 14 March 2011 (UTC)

ifgroup doesn't work

I'm running MediaWiki 1.12 as installed from Debian 5.0's apt archives and SimpleSecurity-MW1.15-r48734.tar.gz. With this combination, the #ifgroup function always returns false. Looking closer, I see the problem is a case of not going all the way when converting a string to lowercase. The offending section of code is in SimpleSecurity itself:

public function ifGroup( &$parser, $groups, $then, $else = '' ) {                
  global $wgUser;
  $intersection = array_intersect( array_map( 'strtolower', split( ',', $groups ) ), $wgUser->getEffectiveGroups() );
  return count( $intersection ) > 0 ? $then : $else;
}

Look at the two parameters passed to array_intersect(). One of them is run through strtolower and the other is not. As-is, this function works correctly only if the group names defined in LocalSettings.php is in all lowercase. You might want caps in a group name and there seems to be no warning against that. Therefore we need to also apply strtolower to the user's effective groups. Here is the corrected line:

$intersection = array_intersect( array_map( 'strtolower', split( ',', $groups ) ), array_map( 'strtolower', $wgUser->getEffectiveGroups() ) );

I don't know if this is addressed in the current subversion code, but here's the fix for those of you who don't want to risk instability. Frotz 20:39, 22 March 2010 (UTC)

MW 1.15.1

->Sorry, this extension requires at least MediaWiki version 1.12.0

any ideas?

not compatible to MW 1.16.0 beta 2

I´m getting the following error: Fatal error: Declaration of DatabaseSimpleSecurity::fetchObject() must be compatible with that of DatabaseBase::fetchObject() in /home/bluewater-info/public_html/wiki/extensions/SimpleSecurity/SimpleSecurity.php(432) : eval()'d code on line 15

--Tkrueger73 14:54, 11 April 2010 (UTC)

Hi. I just checked out revision Revision 69784 and it works fine with 1.16 beta 3. So it looks like it was fixed! Thanks to the author(s)!

--mitchelln 13:44, 23 July 2010 (UTC)

Unreadable links not working (MediaWiki 1.14.0, SimpleSecurity Version 4.3.0)

"$wgSecurityAllowUnreadableLinks = false" doesn't seem to convert unreadable links to plain text. On the extension main page it says that "Still has some bugs to iron out". Does it mean that currently this functionality is not there?

An example here (links to pages in namespace Associazione should be greyed out), MW 1.14.0, SS 4.4.3. --Nemo bis 21:15, 31 July 2010 (UTC)

Filed as bugzilla:25228. --Nemo 17:28, 20 September 2010 (UTC)

Successfull setup with MW1.16.0, but usage question

Hello, I've just setup the SimpleSecurity plugin with MW1.16.0 and it works fine directly out of the box. (without the DBhook as it seems to introduce quite some problems)
I did some initial testing, and basic functionality works correct. However I'm having a problem with a functionality which seems rather trivial, but I don't succeed in configuring it.
What I want is the ability to have pages that are readable by one group say 'readers', and editable/readable by another group say 'editors'. I want the editors to have the possibility to change the page protection:
So I define two extra groups:

$wgSecurityExtraGroups = array(
    'readers' => 'Group having read access',
    'editors' => 'Group having read and write access'
);
$wgGroupPermissions['editors']['protect']          = true;

When going to the protect tab as a member of the 'editors' group:

• Edit: select 'editors'
• Move: select 'editors'
• Read: select 'readers' , I can't do a multiselect :-(

When going back to the page I receive:

'''Permission error'''
You are not allowed to execute the action you have requested. 

I think (but not sure) this is because the editors don't have the 'read' access.
I thought I had found a way to bypass this: give the 'editors' group the 'readers' right.
So I added:

$wgGroupPermissions['editors']['readers']          = true;

When looking at the special page 'User group rights' I see that I should have access, however trying to access the page still results in a permission error.
Any ideas on how to configure this? (I think access restrictions by category should work, but I prefer the per page approach.) I see that this plugins defines some extra logging pages, but I can't find more details on why access is refused. Can I activate somehow detailed logging for this plugin ?
Thanks in advance for your answers.

Redirect Bypass

I just enabled SS for my wiki. I then added the following restriction:

$wgPageRestrictions['Category:Clients']['read'] = array('Administrators');

When I log in as a non-Administrator and access a page in this Category, I get a permission denied error. However, I can access a page in this category as a non-Administrator when I go to a page that redirects to a page in this category. It's only when I click on a direct link to the page or type the exact page URL do I get the Permission Denied error. Therefore any user that knows of a page they don't have access to could just create a new page called whatever, add a redirect to the page they want to access, and then be able to bypass the security and get to the page. Is this a known issue? Does anyone else see this? --Gkullberg 16:23, 23 September 2010 (UTC)

I get a permission denied also on redirects and when I transclude redirects to restricted pages, so works for me. I'm using MediaWiki 1.14.0, SimpleSecurity 4.4.3. --Nemo 11:27, 7 December 2010 (UTC)

Can I restrict create page in category?

I tried the following in my LocalSettings.php, the idea is to restrict create and edit articles in Meetings category to users in the gerente group:

$wgPageRestrictions['Category:Meetings']['edit'] = array('gerente'); // works
$wgPageRestrictions['Category:Meetings']['create'] = array('gerente'); // does not work

But create had no effect, any user can create pages in that category. After that, only users in the gerente group can edit that, as expected!

So, is there anything else I should do to restrict the permissions to create new pages in a category?

Best regards, Matheus Garcia 10:38, 28 October 2010 (UTC)

I don't think there's a way to handle this: even if you don't create a page with that category, you could create a page without a category or with another category. The "strange" thing is that you can add to a page a category which then prevents you to edit or even read that page. --Nemo 11:23, 7 December 2010 (UTC)

Break Special:UnusedFiles and Special:AncientPages

I have determined that this extension breaks both special pages, UnusedFiles and AncientPages, on two of my installations. With SimpleSecurity enabled, the pages err out with:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

    SELECT 'Unusedimages' as type, 6 as namespace, img_name as title, EXTRACT(epoch FROM img_timestamp) as value, img_user, img_user_text, img_description FROM `image` LEFT JOIN `imagelinks` ON img_name=il_to WHERE il_to IS NULL ORDER BY value LIMIT 50 

from within function "". Database returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'epoch FROM img_timestamp) as value, img_user, img_user_text, img_descriptio' at line 1 (localhost)".

When I disable the extension, the pages immediately start working again. Any thoughts on what might be causing this? I'm running 1.16.0, on WIMP.    Thorncrag   03:47, 16 November 2010 (UTC)

Not working and Bug message on 1.16.1

MediaWiki 1.16.1
PHP 5.3.2-1ubuntu4.6 (apache2handler)
MySQL 5.1.41-3ubuntu12.8
--88.131.41.82 18:17, 31 January 2011 (UTC)

Gets following error message when running SimpleSecurity:

Detected bug in an extension! Hook SimpleSecurity::onUserGetRights failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

#0 /var/lib/mediawiki/includes/User.php(2078): wfRunHooks('UserGetRights', Array)
#1 /var/lib/mediawiki/includes/User.php(2228): User->getRights()
#2 /var/lib/mediawiki/includes/Title.php(1560): User->isAllowed('read')
#3 /var/lib/mediawiki/includes/Wiki.php(158): Title->userCanRead()
#4 /var/lib/mediawiki/includes/Wiki.php(59): MediaWiki->preliminaryChecks(Object(Title), Object(OutputPage), Object(WebRequest))
#5 /var/lib/mediawiki/index.php(117): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#6 {main}

Bugfixes or workarounds anyone? --88.131.41.82 18:17, 31 January 2011 (UTC)

Try to use Trunk version of extension (checkout from http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/SimpleSecurity/). I had a same problem on REL1_16 branch. Now I use the trunk version and all works good. Kabanoff 08:13, 11 February 2011 (UTC)

Overview Page

I am using your extensions for a while now. It works pretty flawless, and thats why I was asking myself if theres any chance to generate a overview page with all the page rights set? Like this:

Namespace	Page	Edit	Move	Read
Default	Testsite	Administrators	Administrators	everybody

this would be a really nice feature, expecially if someones forgot to set rights on a page, and I was asking myself if this is even possible to achieve.

Thanks for an answer already. -- Maik 129.233.1.247 15:39, 28 March 2011 (UTC)

Permission Error Message

Ok technically things are working fine, but the message that is displayed says that you need to be part of the Users and my group to access the content. I only want it to say my group. What am I missing (See below).

I have a set of files that I have added to the "JICM_Files_-_Protected" category when I uploaded them. I want to not allow users to see the File: page. I know there are bigger issues with trying to protect files so that they aren't downloaded (img_auth), but for right now I just want the permission message to be correct. Here is my setup.

$wgGroupPermissions['jicm']['read'] = true;
$wgPageRestrictions['Category:JICM_Files_-_Protected']['read'] = 'jicm';

If my account is not part of the jicm group I get the following message on the File page:

Permission error
The action you have requested is limited to users in one of the groups: Users, jicm.

How can the Users group not be listed? What am I missing. I know that the Users group has read access throughout the website, but not for these files. The message is wrong.

Wolcott 15:21, 22 April 2011 (UTC)

IMG_AUTH and SimpleSecurity

Does SimpleSecurity and IMG_AUTH work together? I guess the better way to ask the question is "Does img_auth detect the restrictions that SimpleSecurity applies"? Thus if I restrict a category for read only by a certain group and place files in the category will img_auth restrict the download?

Wolcott 16:07, 22 April 2011 (UTC)

Problem in my Wiki 1.16.5 (PHP-5.3.6, MySQL-5.1.57)

Warning: Parameter 1 to SimpleSecurity::onUserGetRights() expected to be a reference, value given in /~/wiki/includes/Hooks.php on line 133
Thanx and best regards --Ancayman 18:40, 12 May 2011 (UTC)

Solution

I also ran across this issue with the same versions of MW / PHP, and the above fix to change language.php was not the solution as this was already implemented in the newer versions of MW. To resolve, edit SimpleSecurity_body.php, line 168, and remove the & from &$user, as follows:

public function onUserGetRights( &$user, &$rights ) {

This resolved it for me.

--Jlemley 16:48, 3 June 2011 (UTC)

wgSecurityUseDBHook breaks categories/maintenance scripts

I've noticed that membership in my "Private" category (read access restricted to certain groups) seems very finicky. One day, a page will belong to the category; the next day, despite the text of the page not changing, it won't. Of course this means that I can't rely on the protection I'm expecting to get from SimpleSecurity.

When a page is in an inconsistent state, its source will contain "[[Category:Private]]" and its footer will claim that it belongs to the category, but it will not display the "security restrictions" disclaimer, nor appear in the index on page "Category:Private". As a workaround, once the problem is noticed, it can be fixed (for that page) by performing a null edit.

I tracked the problem to $wgSecurityUseDBHook. With that flag set, I can reproduce the bug as follows:

1. Create a new page, "Test", containing "[[Category:Private]]"; observe that it appears in the category index.
2. Run the rebuildall.php maintenance script; observe that "Test" no longer appears in the category index.
3. Run rebuildall.php again; observe that "Test" has returned to the category index.

I noticed that the only pages that appear in the index after a rebuildall are the ones that didn't appear there before the rebuildall. I'm guessing that the DB hook prohibits the maintenance script from seeing read-protected pages; as a result, all read-protected pages are considered by the script to be empty, and so they are removed from the category index.

For now, I'm turning off the DB hook. Any advice on the security implications of doing so? Only trusted users have write access to my wiki; but would certain special pages or searches expose content from the private pages?

Versions: MediaWiki 1.16.5, PHP 5.3.4, MySQL 5.1.44, SimpleSecurity 4.5.1

Smith.dan 19:34, 6 June 2011 (UTC)

Workaround for MW 1.21, 1.23 for conflict with maintenance/refreshLinks.php

Good news: The extension is running with MW 1.23. The problem described, however, still occurs with this version. The script maintenance/refreshLinks.php which is also invoked from maintenance/rebuildall.php removes links from pages in protected namespaces from the tables category and categorylinks. The links are however still present on the wiki pages and after some time of wiki use (or saving the pages again) the links reappear on the wiki pages.

Workaround:

• deactivate extension SimpleSecurity for running maintenance/refreshLinks.php oder maintenance/rebuildall.php
• reactivate it afterwards

Kappa (talk) 10:11, 4 November 2014 (UTC)

Problem with the <security-info> Tag

Hi! I've got the little Problem that on secured sites I have this Tag <security-info>. I think this should show some Security Informations and not only the tag. What can I do that this work? THX!

MW 1.17 DB hook broken

In MW 1.17, if $wgSecurityUseDBHook = true, MW returns a blank page with no other errors.

Affirmative. It also prevents MediaWiki from updating to 1.17.0. You will get "PHP Fatal error: Call to a member function isOpen() on a non-object in /.../LoadBalancer.php on line 652" --[[kgh]] 14:22, 23 June 2011 (UTC)

Yes, this error also appears if you enable PHP debugging after it is installed. I have had to roll back to 1.16 because of this. Any ideas?

I have not tested so far, but I am utterly sure that Nad has done a very good job to port this extension to MW 1.17 :) Cheers --[[kgh]] 11:31, 24 June 2011 (UTC)

for me, there is the same problem. without the usedbhook or setting this to false everything works fine.

Just tried it again, and it works!! Had to use the trunk version and not 1.17 though. Thanks Nad!!!

Tried it again, too with the newest svn checkout. It works! The last Snapshot from 2011-06-24 didn't work! THX

Fatal error: Class 'SimpleSecurity' not found in xxx\SimpleSecurity.php on line 73

On step 2 of the MW1.17.0 installation/update routine I still get a fatal error, even with the trunk version of SimpleSecurity 5. Since this script is an integral part of my MW-intranet, I need to make sure the system works before updating the database. Can someone please a) confirm that the extension will work after completion of the installation process or b) point out a solution to the error. Thanks! --docMario, 129.206.90.2 06:50, 30 June 2011 (UTC)

I can now answer my own questions:

a) the extension works after upgrading the database

b) installation routine runs smoothly by adding require_once('SimpleSecurity_body.php'); to SimpleSecurity.php.

best regards, --docMario, 129.206.90.2 11:22, 1 July 2011 (UTC)

Conflict with AWC Forum extension

If you include both SimpleSecurity and AWC Forum (latest versions for 1.17 as of 7/12/2011), you can't configure AWC Forum. Any attempt results in a database error. This even happens when no SimpleSecurity settings are modified, and it happens regardless of include order.

Override security with transclusion

A user who can't view a category can still create a new page and transclude a page in that category. The namespace I'm transcluding from has a space in its name. I tried transcluding with {{Bla Bla:Stuff}} and {{Bla_Bla:Stuff}}, and both worked.

Upgrade from MW 1.16 to 1.17 removes read protection?

I would like to upgrade my Mediawiki version from 1.16 to 1.17. I'm currently using Simple Security 4.5.0. Using the update.php method works with the latest trunk version. However, I find that all of the read protections are no longer working. As an example, if I log out and try to view a restricted page, it makes me log in before I can view it. After the update, I can see any protected pages. It does give me a warning that there are restrictions on the page, but I can see everything. Am I missing something? I've reverted back to 1.16 and 4.5.0 until I can figure this out.

Confirmed, if Extension:ConfirmAccout is enabled. Seems similar to the bug descibed earlier #SimpleSecurity (50406) doesn't play well with ConfirmAccount --217.91.154.83 10:55, 11 August 2011 (UTC)

Thanks. Right now, the only extensions I have are Graphviz, SimpleSecurity, and FileProtocolLinks. I wouldn't think the other two would conflict, but anything's possible.

Any solution yet? Have the same problem, but no Extension:ConfirmAccout. Security conditions are working so I use this as a poor workaround to hide some critcal informations Mirco

MW 1.17: Epic fail

It seems that Extension:SimpleSecurity NOT WORKS AT ALL!!! I'm very angry, that I spend so many time for attempts to create restriction system with this extension! 16:43, 13 August 2011 (UTC)

Doc/File help and Bug

MW 1.16.5 / PHP 5.2.17 / MySQL 5.0.91 / Vector Skin

Simple Testing so far. Issues I've noticed

1. File List: You protect an file/img/etc, to administrator only. Displays the message about security rights, but the user can still click on the link and have the file/img/etc displayed. Both $wgUploadPath = "$wgScriptPath/img_auth.php"; and $wgUploadDirectory = "images"; have been set inside the LocalSettings.php. Have tried these settings before and after the call to SimpleSecurity.php
2. Using the Vector skin, $wgSecurityAllowUnreadableLinks = false; only partially works, the link for cur is missing, while the link for prev is still functional
3. Searching. Is there a way to a page, if protected, not displayed when a search is done? When a search is done, it does display the link title, and the permission warning in the extract, but that still gives an indication that there is somethign in the article related to the original searched term.
   

Lynxcub 16:42, 24 August 2011 (UTC)

Parameter 1 to SimpleSecurity::updateLB() expected to be a reference, value given

I'm getting the following Warning:

Warning: Parameter 1 to SimpleSecurity::updateLB() expected to be a reference, value given in includes/db/LBFactory.php on line 211

I'm using MediaWiki 1.17 and PHP 5.3.6. The extension seems to work as expected, can I ignore the warning? Or should I change something? Thanks for answers!

To avoid to full the log you can modified updateLB function in SimpleSecurity_body.php
before

static function updateLB( &$lb ) {
        $lb->closeAll();
        foreach ( $lb->mServers as $i => $server ) $lb->mServers[$i]['type'] = 'SimpleSecurity';

after

static function updateLB( $lb ) {
        $lb->closeAll();
        foreach ( $lb->mServers as $i => $server ) $lb->mServers[$i]['type'] = 'mysql';

MW 1.17

The Extension seems to work just fine for me in MW 1.17. See: Off Grid Ops. If you try to use any of the Special Pages or anything that requires the Category of Property Forms you are sent to the Login. Now, I'm no coder, but that seems to do what I want; simply block a category or two and the Special Pages.

I added the .css stuff and didn't see any kind of change, though. No big deal as I am a pretty old school person and simply like the plain jane mediawiki anyway.

Thanks for the extension! --Coffeehound 18:09, 31 August 2011 (UTC)

MW 1.17

The Extension seems to work just fine for me in MW 1.17. See: Off Grid Ops. If you try to use any of the Special Pages or anything that requires the Category of Property Forms you are sent to the Login. Now, I'm no coder, but that seems to do what I want; simply block a category or two and the Special Pages.

When I set the DB Hook to true I get:

Fatal error: Call to a member function isOpen() on a non-object in /home/offgrido/public_html/foreclosurepedia/includes/db/LoadBalancer.php on line 652

I added the .css stuff and didn't see any kind of change, though. I mean I get no tabs nor dropdowns like in your screenshots. This is simply some notations by me to help should you pursue making things work in MW 1.17.

I would, though, appreciate it if there is a way you may know of to simply lockdown the Category and Namespace areas without the extension. I mean if it is doing its job great; however, if it isn't really necessary for what I am trying to achieve I would be obliged to know.

Thanks for the extension! --Coffeehound 18:16, 31 August 2011 (UTC)

Hi, I got the same fatal error enabling DB Hook to true. I'll use it without that option hoping it won't open a security hole. Bye.

Alex

SimpleSecurity doesn't seem to work in Mediawiki 1.18.0

Hi,

I downloaded Simplesecurity extension for mediawiki 1.18.0 and added the following lines of code to Localsettings.php file as well.

require_once("{$IP}/extensions/SimpleSecurity/SimpleSecurity.php"); $wgSecurityUseDBHook = true; $wgSecurityRenderInfo = true; $wgSecurityAllowUnreadableLinks = false; $wgPageRestrictions['Category:Servers']['read'] = 'sysop';

  My objective is to create a page which only the administrators can view/edit. 

So I created a page and gave read,edit access to only administrators using Protect option.

But when I log out and do a search for this page using the search button, the restricted page
shows up with full content though there is a message on the top saying 

"There are security restrictions on this page".

    Am I missing something? Thanks in advance for your help.

Hi, same problem here with 1.18.
Logged in I get from a "restricted page":

There are security restrictions on this page
   * read is restricted to the sysop group (applies because this page is in the "Private namespace")
   * read is restricted to the sysop group (set from the "protect" tab)
   * No restrictions are in effect because you are a member of the "sysop" group
Full page text...

Logged out I get:

There are security restrictions on this page
   * read is restricted to the sysop group (applies because this page is in the "Private namespace")
   * read is restricted to the sysop group (set from the "protect" tab)
Full page text (Nothing is restricted as it should be...)

Hi,

I did find an alternative for this issue and it works. Create a Restricted Category 

and create pages under that category. Then this problem can be averted.

I am using the latest version from the trunk 111260, and have my LocalSettings.php look like this

* $wgSecurityUseDBHook = true;
* require_once("{$IP}/extensions/SimpleSecurity/SimpleSecurity.php");

Working properly for me, when not logged in for page and category blocks.

No go for MW 1.18.1: The Restricted Category does nothing. I am REALLY in hopes this plugin can be brought up to 1.18.x as I really depended upon it in 1.17.x! My Site's Example --Coffeehound 04:47, 8 February 2012 (UTC)

Semantic MediaWiki Issue

Hi, thanks for the nice and simple to use security plugin. Currently I am running Semantic MediaWiki 1.6, MediaWiki 1.17, with SimpleSecurity 5.0.4 and appear to have run into an issue with semantic housekeeping/maintenance tasks. I have pages protected by restricting access to an entire namespace. When I run the SMW_refreshData.php script as described here: http://semantic-mediawiki.org/wiki/Help:Repairing_SMW%27s_data#Using_the_SMW_maintenance_script the pages in the restricted namespace will not actually save semantic data. Or in other words, run the refresh data script, navigate to page in namespace, and click "Browse properties" which will be empty. Commenting the extension, and running the script works fine. Also, with the SimpleSecurity extension enabled, saving the pages by hand works fine as well. Any ideas? I'm also looking to switch to 1.18 but am hoping to get a better understanding of this issue before transitioning.

Usuario conectado debe estar en el grupo para verlo

Trabajo con Mediawiki 1.14.

Configuré toda la extensión para dar permisos a un ExtraGroup pero no lograba verlo en la lista de grupos.

El problema se soluciona si el usuario conectado en mediawiki (el que está definiendo la protección) está dentro del nuevo ExtraGroup.

Remove "There are security restrictions on this page" text?

Loving the Extension, does exactly what I wanted and has meant my sticking with MediaWiki over choosing a different product.

The only thing which is just a tiny bit annoying is the "There are security restrictions on this page" text which appears on every single page (I use it on two wikis, one which is mainly read only for all but me and another which is similar but has a group of users able to edit)

I'm using MediaWiki 1.18 and the Wikis in question are; http://www.roleplayers.eu/ & http://www.thewrestlingarchive.net/.

Any help may be worth cookies*

Chris

* Cookies are entirely fictional and intended only to prompt a reply.

The extension uses a set of system messages (which are pages in the MediaWiki namespaces). They can be found with the Special:AllMessages page on your wiki's, and all start with "security". Here are these message on www.thewrestlingarchive.net [1]. You can change these texts by creating these pages, overwriting the default message with your own text. To simply remove a message you can create a blank page instead. Of course this means that the message will be gone on all pages. So, if you want the message on some pages but not on others, this isn't a solution. MrBlueSky 17:01, 11 February 2012 (UTC)

In your case you would probably want to create an empty page called MediaWiki:Security-info. MrBlueSky 17:03, 11 February 2012 (UTC)

SimpleSecurity::updateLB() once again

I am getting the following two warnings 11 times after every question:

PHP Warning:  Parameter 1 to Language::getMagic() expected to be a reference, value given in /usr/share/mediawiki/includes/StubObject.php on line 58
PHP Warning:  Parameter 1 to SimpleSecurity::updateLB() expected to be a reference, value given in /usr/share/mediawiki/includes/db/LBFactory.php on line 184

I tried modifiing function updateLB as written above - no change.

I am using debian squeeze:

• mediawiki 1.15.5
• PHP 5.3.3
• mysql 5.1.49

Thank you for answers.--Gyimhu 18:37, 13 February 2012 (UTC)

MW 1.18.1

So, the extension works for me now. I found I needed to include both edit and read. I still have never seen the tabs displayed on your extension and would really like to. Any help in this direction would be great!--Coffeehound 02:02, 15 February 2012 (UTC)

Change label on protection page

I'm trying to change the label 'read' in protection page to my language, but i can't do this. This label shows the value of this property $wgSecurityExtraActions, but if I change the first parameter of the array the extension doesn't work; if I change the value, it doesn't change anything.

I've tried it: $wgSecurityExtraActions = array( 'read' => 'Ler' ); $wgSecurityExtraActions = array( 'ler' => 'Read' );

How could I solve it?

I'm using MW 1.17.1

Thanks

Same tolower bug I found in 2010 still present

I installed a new wiki and needed to have SimpleSecurity again. I was rather dismayed to find that the same bug I found in 2010 (see above) is still present in the current code. Though the offending code was altered in that time, the bug was not fixed. I'm using MediaWiki 1.18.2 installed from the source tarball (not through Debian APT like last time) and SimpleSecurity1.18-r92088. The fix is identical, but just in case anyone needs more info, here's the bug in detail:

Go to line 90 in SimpleSecurity_body.php. There will be an indented line beginning with "$intersection". Notice that there are is one "strlower" call. This one is applied to an exploded list of $groups. The result compared to an array map acquired from $wgUser->getEffectiveGroups(). That array map must also be made lowercase or else you'll have a situation where "itstaff" is compared with "ITStaff" and they won't match and things like #ifgroup won't work correctly. This is frustrating and embarassing.

The fix, again, is here:

Change this:

$intersection = array_intersect( array_map( 'strtolower', explode( ',', $groups ) ), $wgUser->getEffectiveGroups() );

into this:

$intersection = array_intersect( array_map( 'strtolower', explode( ',', $groups ) ), array_map( 'strtolower', $wgUser->getEffectiveGroups() ) );

Nad, would you PLEASE apply this change to your working code?

Parser functions don't work in the site notice

While #ifgroup or ifusercan works for me in the main and template namespaces, neither of them work when they are used in MW:Sitenotice. At first, the text for logged-in users is shown to both logged-in users and visitors that have not registered/logged in; after a short while, the text disappears for both groups. (Before you ask: yes, I've considered the CentralNotice extension as an alternative, but it appears to be unusable if one's database tables have prefixes.) Cavila ^{MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.8} 20:20, 18 January 2013 (UTC)

Never mind. It's a limitation without great consequences, because MediaWiki:Anonnotice and MediaWiki:Sitenotice can be used to differentiate between a sitenotice for logged-in users and another for anonymous users. Cavila ^{MW 1.19.2, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.1} 11:59, 28 January 2013 (UTC)

How to choose multiple groups in the per page protection in Vector skin in Mediawiki 1.20.3?

How to choose multiple groups in the per page protection in Vector skin in Mediawiki 1.20.3? I want to give read permissions to more than 3 custom user groups as I have a total of 14 custom user groups. How can I select multiple groups .please reply ASAP.--Satyamcompany (talk) 17:26, 2 May 2013 (UTC)

How is your setup? Should work like this:

$wgPageRestrictions['Category:ADMIN']['read'] = array('sysop', 'superuser', 'ninja', 'admins');

ifgroup - stop processing or use else?

Is there a way to stop processing further rules or use an else statement for ifgroup?

I have the following:

{{#ifgroup:Brazil|
= Hey Brazil =
}}
{{#ifgroup:India|
= Hey India = 
}}
{{#ifgroup:USA|
= Hey USA =
}}
{{#ifgroup:sysop|
= Hey sysop =
}}

However if a user is both members of Brazil and sysop groups for example, it shows both contents. I'll like a way to satisfy only one condition, is that possible to accomplish?

Error with view history

When clicking the "View history" tab for any user (read restricted, sysop, etc.), the following error appears

Warning: Recursion detected in RequestContext::getLanguage in <WIKI PATH\includes\context\RequestContext.php on line 281

Catchable fatal error: Argument 1 passed to DatabaseBase::__construct() must be of the type array...

Using this Extension with MW 1.26.2 I got the following error:

Catchable fatal error: Argument 1 passed to DatabaseBase::__construct() must be of the type array, string given, called in C:\xampp\htdocs\fywiki26\extensions\SimpleSecurity\SimpleSecurity_body.php on line 455 and defined in C:\xampp\htdocs\fywiki26\includes\db\Database.php on line 627

Since MW 1.23 "__construct()" from Database.php only accept an array instead of parameters. I tried a few methods to got this working without having new errors. The best one is to use the original "reallyOpenConnection()-function" in LoadBalancer.php. I edit line 417 in SimpleSecurity_body.php:

return new LoadBalancerSimpleSecurity( array(
	'servers' => $servers,
	'masterWaitTimeout' => $wgMasterWaitTimeout
));

to using the original LoadBalancer-class:

return new LoadBalancer( array(
	'servers' => $servers,
	'masterWaitTimeout' => $wgMasterWaitTimeout
));

--Dknapke (talk) 09:52, 21 March 2016 (UTC)

wfMessage fix

Below I have included a fix for the security messages at the top of wiki pages. Change "escape()" to "plain()" on lines 141 & 143.

SimpleSecurity_body.php (line 140-144)

# Add info-toggle before title and hidden info after title
$link = "<a href='javascript:'>" . $out->msg( 'security-info-toggle' )->plain() . "</a>";
$link = "<span onClick='toggleSecurityInfo()'>$link</span>";
$info = "<div id='security-info-toggle'>" . $out->msg( 'security-info', $link )->plain() . "</div>\n";
$text = "$info<div id='security-info' style='display:none'>$itext</div>\n$text";

--Dgennaro 16:42, 15 September 2016 (UTC)

getNamespace() is null for Files - bugfix

Simple security was having issues with files

Original line 185-186 of SimpleSecurity_body.php:

if ( !is_object( $wgOut ) ) return true;
$title = $wgOut->getTitle();

Change to:

$title = $wgOut->getTitle();
if ( !is_object( $title ) ) return true;

--Dgennaro 17:58, 28 September 2016 (UTC)

Database Hook Fix

After some tweaking I got SimpleSecurity working again and preventing reads by using the new database hook.

Here is my 'delta' for SimpleSecurity/SimpleSecurity_body.php based in 1.28 (of SimpleSecurity), in "patch" format:

--- SimpleSecurity/SimpleSecurity_body.php      2016-11-18 20:18:47.000000000 +0100
+++ /srv/www/htdocs/wiki/extensions/SimpleSecurity/SimpleSecurity_body.php      2017-01-23 13:22:40.098432472 +0100
@@ -138,10 +138,10 @@
                        );

                        # Add info-toggle before title and hidden info after title
-                       $link = "<a href='javascript:'>" . $out->msg( 'security-info-toggle' )->escaped() . "</a>";
-                       $link = "<span onClick='toggleSecurityInfo()'>$link</span>";
-                       $info = "<div id='security-info-toggle'>" . $out->msg( 'security-info', $link )->escaped() . "</div>\n";
-                       $text = "$info<div id='security-info' style='display:none'>$itext</div>\n$text";
+#                      $link = "<a href='javascript:'>" . $out->msg( 'security-info-toggle' )->escaped() . "</a>";
+#                      $link = "<span onClick='toggleSecurityInfo()'>$link</span>";
+#                      $info = "<div id='security-info-toggle'>" . $out->msg( 'security-info', $link )->escaped() . "</div>\n";
+#                      $text = "$info<div id='security-info' style='display:none'>$itext</div>\n$text";
                }

                return true;
@@ -182,8 +182,8 @@
                global $wgGroupPermissions, $wgOut, $wgRequest, $wgPageRestrictions;

                # Hack to prevent specialpage operations on unreadable pages
-               if ( !is_object( $wgOut ) ) return true;
                $title = $wgOut->getTitle();
+               if ( !is_object( $wgOut ) ) return true;
                $ns = $title->getNamespace();
                if ( $ns == NS_SPECIAL ) {
                        list( $name, $par ) = explode( '/', $title->getDBkey() . '/', 2 );
@@ -439,13 +439,24 @@
                        $server['dbname'] = $dbname = $dbNameOverride;
                }
                wfDebug( "Connecting to $host $dbname...\n" );
-               $db = new Database_SimpleSecurity(
-                       isset( $server['host'] ) ? $server['host'] : false,
-                       isset( $server['user'] ) ? $server['user'] : false,
-                       isset( $server['password'] ) ? $server['password'] : false,
-                       isset( $server['dbname'] ) ? $server['dbname'] : false,
-                       isset( $server['flags'] ) ? $server['flags'] : 0,
-                       isset( $server['tableprefix'] ) ? $server['tableprefix'] : 'get from global'
+# See "includes/libs/rdbms/database/Database.php" 362
+               $db = new Database_SimpleSecurity( [
+                       'host'        => isset( $server['host'] ) ? $server['host'] : false,
+                       'user'        => isset( $server['user'] ) ? $server['user'] : false,
+                       'password'    => isset( $server['password'] ) ? $server['password'] : false,
+                       'dbname'      => isset( $server['dbname'] ) ? $server['dbname'] : false,
+                       'flags'       => isset( $server['flags'] ) ? $server['flags'] : 0,
+                       'variables'   => isset( $server['variables'] ) ? $server['variables'] : [],
+                       'tablePrefix' => isset( $server['tablePrefix'] ) ? $server['tablePrefix'] : '',
+                       'schema'      => isset( $server['schema'] ) ? $server['schema'] : '',
+                       'cliMode'     => isset( $server['cliMode'] ) ? $server['cliMode'] : ( PHP_SAPI === 'cli' ),
+                       'agent'       => isset( $server['agent'] ) ? $server['agent'] : false,
+                       'profiler'    => isset( $server['profiler'] ) ? $server['profiler'] : null,
+                       'trxProfiler' => isset( $server['trxProfiler'] ) ? $server['trxProfiler'] : new TransactionProfiler(),
+                       'connLogger'  => isset( $server['connLogger'] ) ? $server['connLogger'] : new \Psr\Log\NullLogger(),
+                       'queryLogger' => isset( $server['queryLogger'] ) ? $server['queryLogger'] : new \Psr\Log\NullLogger(),
+                       'errorLogger' => isset( $server['errorLogger'] ) ? $server['errorLogger'] : ''
+                       ]
                );
                if ( $db->isOpen() ) {
                        wfDebug( "Connected to $host $dbname.\n" );

-- Peter 13:54, Monday 23 January 2017

Working in 1.28?! wow good work :-) --Nad (talk) 13:56, 23 January 2017 (UTC)

The patch isn't compatible with the latest version, what version is this for? --Nad (talk) 15:18, 23 January 2017 (UTC)

I downloaded SimpleSecurity-REL1_28-dfba34c.tar.gz, hm... what is missing/wrong? -- Peter 16:42, 23 January 2017 (UTC)

I tried to apply the patch to the master branch and to REL1_28 and it's says it doesn't apply in both cases, so the version in the tar.gz must be out of date. --Nad (talk) 09:44, 24 January 2017 (UTC)

I see.... I must have been lucky when I downloaded the snapshot. In the master version SimpleSecurity_body.php is missing some lines at the end. Especially those with the LoadBalancerSimpleSecurity class. It is reference in applyDatabaseHook, but missing in the source. I'll give it a try with the master version and re-implement those functions. Or was there a reason to get rid of them? -- Peter 11:13, 24 January 2017 (UTC)

I have no idea what's been going on with this extension for the last 7years or more, I had given up on it after MW1.17! Someone else must have been maintaining it... I don't actually have commit access anymore, I was just going to test the patch myself and then submit it in a message in phabricator... --Nad (talk) 11:28, 24 January 2017 (UTC)

Ah... that explains a lot. ;-) Here is the patch against the (current) master (basically re-adding the missing and modified hook):

diff -Naur mediawiki-extensions-SimpleSecurity/SimpleSecurity_body.php SimpleSecurity/SimpleSecurity_body.php
--- mediawiki-extensions-SimpleSecurity/SimpleSecurity_body.php 2017-01-24 11:52:01.201651074 +0100
+++ SimpleSecurity/SimpleSecurity_body.php      2017-01-24 12:17:02.100698504 +0100
@@ -397,3 +397,79 @@
        }

 }
+
+/**
+ * The new LBFactorySimpleSecurity class identical to LBFactorySimple except that it returns a LoadBalancerSimpleSecurity object
+ */
+class LBFactorySimpleSecurity extends LBFactorySimple {
+
+       function newMainLB( $wiki = false ) {
+               global $wgDBservers, $wgMasterWaitTimeout;
+               if ( $wgDBservers ) {
+                       $servers = $wgDBservers;
+               } else {
+                       global $wgDBserver, $wgDBuser, $wgDBpassword, $wgDBname, $wgDBtype, $wgDebugDumpSql;
+                       $servers = array(array(
+                               'host' => $wgDBserver,
+                               'user' => $wgDBuser,
+                               'password' => $wgDBpassword,
+                               'dbname' => $wgDBname,
+                               'type' => $wgDBtype,
+                               'load' => 1,
+                               'flags' => ($wgDebugDumpSql ? DBO_DEBUG : 0) | DBO_DEFAULT
+                       ));
+               }
+               return new LoadBalancerSimpleSecurity( array(
+                       'servers' => $servers,
+                       'masterWaitTimeout' => $wgMasterWaitTimeout
+               ));
+       }
+
+}
+
+// Backward compatibility since MediaWiki 1.23
+class_alias( 'LBFactorySimpleSecurity', 'LBFactory_SimpleSecurity' );
+
+/**
+ * LoadBalancerSimpleSecurity always returns Database_SimpleSecurity regardles of $wgDBtype
+ */
+class LoadBalancerSimpleSecurity extends LoadBalancer {
+
+       function reallyOpenConnection( $server, $dbNameOverride = false ) {
+               if( !is_array( $server ) ) {
+                       throw new MWException( 'You must update your load-balancing configuration. See DefaultSettings.php entry for $wgDBservers.' );
+               }
+               $host = $server['host'];
+               $dbname = $server['dbname'];
+               if ( $dbNameOverride !== false ) {
+                       $server['dbname'] = $dbname = $dbNameOverride;
+               }
+               wfDebug( "Connecting to $host $dbname...\n" );
+# See "includes/libs/rdbms/database/Database.php" 362
+               $db = new Database_SimpleSecurity( [
+                       'host'        => isset( $server['host'] ) ? $server['host'] : false,
+                       'user'        => isset( $server['user'] ) ? $server['user'] : false,
+                       'password'    => isset( $server['password'] ) ? $server['password'] : false,
+                       'dbname'      => isset( $server['dbname'] ) ? $server['dbname'] : false,
+                       'flags'       => isset( $server['flags'] ) ? $server['flags'] : 0,
+                       'variables'   => isset( $server['variables'] ) ? $server['variables'] : [],
+                       'tablePrefix' => isset( $server['tablePrefix'] ) ? $server['tablePrefix'] : '',
+                       'schema'      => isset( $server['schema'] ) ? $server['schema'] : '',
+                       'cliMode'     => isset( $server['cliMode'] ) ? $server['cliMode'] : ( PHP_SAPI === 'cli' ),
+                       'agent'       => isset( $server['agent'] ) ? $server['agent'] : false,
+                       'profiler'    => isset( $server['profiler'] ) ? $server['profiler'] : null,
+                       'trxProfiler' => isset( $server['trxProfiler'] ) ? $server['trxProfiler'] : new TransactionProfiler(),
+                       'connLogger'  => isset( $server['connLogger'] ) ? $server['connLogger'] : new \Psr\Log\NullLogger(),
+                       'queryLogger' => isset( $server['queryLogger'] ) ? $server['queryLogger'] : new \Psr\Log\NullLogger(),
+                       'errorLogger' => isset( $server['errorLogger'] ) ? $server['errorLogger'] : ''
+                       ]
+               );
+               if ( $db->isOpen() ) {
+                       wfDebug( "Connected to $host $dbname.\n" );
+               } else {
+                       wfDebug( "Connection failed to $host $dbname.\n" );
+               }
+               $db->setLBInfo( $server );
+               return $db;
+       }
+}

I'd like to remind people to enable the $wgSecurityUseDBHook = true; line in their LocalSettings.php to enable the code. -- Peter 12:47, 24 January 2017 (UTC)

Any chance of getting this fixed so it would be easy to use a Public category for anyone other than authorized users: doesn't work for '*' group, for example $wgPageRestrictions['Category:Public']['read'] = '*' fails.

Default Group Permissions READ

if use $wgGroupPermissions['*']['read'] = true; permissions READ not work. So should be??

dosn't work on MW 1.30

I'm missing the extension.json file

[Tue May 22 09:58:21.334790 2018] [:error] [pid 19306] [client 10.62.19.137:53106] 
PHP Fatal error:  Uncaught Exception: /srv/web-tz/htdocs/tzvwiki/extensions/SimpleSecurity/extension.json does not exist! in /srv/web-tz/htdocs/tzvwiki/includes/registration/ExtensionRegistry.php:99\nStack trace:\n
#0 /srv/web-tz/htdocs/tzvwiki/includes/GlobalFunctions.php(120): ExtensionRegistry->queue('/srv/web-tz/htd...')\n
#1 /srv/web-tz/htdocs/tzvwiki/LocalSettings.php(152): wfLoadExtension('SimpleSecurity')\n
#2 /srv/web-tz/htdocs/tzvwiki/includes/WebStart.php(102): require_once('/srv/web-tz/htd...')\n
#3 /srv/web-tz/htdocs/tzvwiki/index.php(40): require('/srv/web-tz/htd...')\n
#4 {main}\n  thrown in /srv/web-tz/htdocs/tzvwiki/includes/registration/ExtensionRegistry.php on line 99, referer: http://tza.litef.de/tzvwiki/index.php/Spezial:Spezialseiten

can someone help --Joergens.mi (talk) 08:15, 22 May 2018 (UTC)

i don't get error on 1.30. I get new Read widgets on Protect tab. Problem tho, namespace read restriction doesn't seem to work.

Not Working on 1.30

Hi, using the Git master.

I can install no prob,and view/edit wiki no probs.

No errors, even in verbose mode.

I get new read widgets on protect tab.

But, protection doesn't seem to actually work. Neither per-page, nor per-namespace.

I have a custom namespace called Portal. None of these work. Other user-groups can view pages in the Portal ns.

$wgPageRestrictions['Namespace:3004']['read'] = 'WikiSysop';
$wgPageRestrictions['Namespace:Portal']['read'] = 'WikiSysop';
$wgPageRestrictions['Namespace:'.NS_PORTAL]['read'] = 'WikiSysop';
$wgPageRestrictions['Namespace:3004']['read'] = 'sysop';
$wgPageRestrictions['Namespace:Portal']['read'] = 'sysop';
$wgPageRestrictions['Namespace:'.NS_PORTAL]['read'] = 'sysop';
$wgPageRestrictions['Namespace:3004']['read'] = 'Administrators';
$wgPageRestrictions['Namespace:Portal']['read'] = 'Administrators';
$wgPageRestrictions['Namespace:'.NS_PORTAL]['read'] = 'Administrators';
$wgPageRestrictions['Namespace:3004']['read'] = array('sysop', 'WikiSysop', 'Administrators');
$wgPageRestrictions['Namespace:Portal']['read'] = array('sysop', 'WikiSysop', 'Administrators');
$wgPageRestrictions['Namespace:'.NS_PORTAL]['read'] = array('sysop', 'WikiSysop', 'Administrators');

Anyideas? How can i troubleshoot this?