Extension talk:SimpleSecurity

From MediaWiki.org

Jump to: navigation, search

Contents

[edit] 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)

[edit] 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. http://www.mediawiki.org/wiki/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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] $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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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.

[edit] Breaks CategoryCloud extension?

This appears to break the extension CategoryCloud (running MW 1.12): http://www.mediawiki.org/wiki/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)

[edit] 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.

[edit] 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

[edit] 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

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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.

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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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?

[edit] 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?


[edit] 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)

[edit] 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.

[edit] 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)

[edit] {{#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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Bug issue with trunk 1.16a version

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

[edit] 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)


[edit] 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)

[edit] 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


[edit] Security bug

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

[edit] 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)

[edit] 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)


[edit] Two questions

[edit] 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.


[edit] 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

Retrieved from "http://www.mediawiki.org/wiki/Extension_talk:SimpleSecurity"