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)

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)