Extension talk:SimpleSecurity/Archive

ifUserCan bugfix
-	public function ifUserCan(&$parser, $action, $title, $then, $else = '') { return $title->userCan($action) ? $then : $else; } +	public function ifUserCan(&$parser, $action, $title, $then, $else = '') { $oTitle = Title::newFromText( $title ); return $oTitle->userCan($action) ? $then : $else; } otherwise it will crash as title is simple string

--Eugenem 13:10, 10 August 2008 (UTC)
 * oops, thanks will update asap :-) --Nad 11:17, 12 August 2008 (UTC)
 * 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
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)

errors with 1.10.1
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 = --Rob 20:02, 24 August 2008 (UTC)
 * MediaWiki: 1.10.1
 * PHP: 5.2.0-8+etch11 (cgi-fcgi)
 * MySQL: 5.0.32-Debian_7etch6-log
 * 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
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
I Need to define a category which can only be edited by a particular group. I've done the following in LocalSettings.php:

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

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

$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)
 * 1) Security
 * 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)

not an action group permission
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
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
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)

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