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)

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)

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':

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)

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)
 * I don't really know what exactly to look for since I'm not experiencing the same problems on any of my local installations, I just thought if I could check it out I may be able to shed some light on it. Perhaps try doing a print_r($GLOBALS) at the point just before it attempts the failing preg_match_callback - it'll be big, so maybe mail the output to aran at organicdesign.co.nz rather than adding it here. Another thing you could try is making the patchSQL function global instead of a method of SimpleSecurity and removing the preceding SimpleSecurity:: from where it's called in the query function. --Nad 22:40, 29 August 2008 (UTC)
 * I think I may have found your 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)