Extension talk:Restrict access by category and group

Modifications and updates.

v: 1.01

• Supressed warning when you don't define $wgWhitelistRead array.

Error: Headers already sent

Solution:

• Edit e.g. DefaultSettings.php with Notepad++ and then select the encoding Encode in UTF-8 without BOM (Guus)

• Hi, when I add your extension I get some "Headers already sent" errors on my wiki. I'm shure I installed the stuff properly. --JazzmanDE 14:14, 17 September 2008 (UTC)

Solution:

• You must put the code into <?php and ?> tags (no more spaces neither blank lines before/after the block). If do not, you get this message because php thinks that is html not php code. See installation section for more detail.
• Thanks! --JazzmanDE 14:53, 22 September 2008 (UTC)

• Hi, I'm getting this Error:

Warning: Cannot modify header information - headers already sent by (output started at ::C:\xampp\htdocs\MinjusWiki\LocalSettings.php:1) in C:\xampp\htdocs\MinjusWiki\includes\WebResponse.php on line 10

Warning: Cannot modify header information - headers already sent by (output started at ::C:\xampp\htdocs\MinjusWiki\LocalSettings.php:1) in C:\xampp\htdocs\MinjusWiki\includes\WebResponse.php on line 10 --JimHawk 10:24, 18 November 2008 (UTC)

Trace:

• Did you put require_once("$IP/extensions/rabcg/rabcg.php"); between <?php and ?> tags in your LocalSettings.php? Nearly all LocalSettings.php files are <?php but there isn't ?>. So you must put it between <?php and the end of file. --Lodopidolo 22:44, 18 November 2008 (UTC)

• Well I've tried to put the line "require_once("$IP/extensions/rabcg/rabcg.php");" between the "<?php" an the end of the file. At the end of my "LocalSettings.php", there's no "?>". Therefore I've made a provisional one (?>) an I've put the line there after between "<?php" and "?>". Both methods had the same result ("Warning: Cannot modify header information - headers already sent by..."). Is it possible that the problem depends on the fact that i possess another language version of Mediawiki as english? Thanks in advance. --JimHawk 09:21, 19 November 2008 (UTC)

• No, It is language independent. ?> tag isn't necessary. I think that the problem is in rabcg.php and/or groups.php. Is important that there isn't any blank line neither spaces before <?php tag. This tag must be the first thing in these files. Is this correct in your files? --Lodopidolo 18:19, 24 November 2008 (UTC)

• Yes, i have no blank lines or spaces before <?php Tag. It's really the first thing in my files. Must i install something else, unless the ExtensionFunctions.php, rabcp.php and the groups.php files? --JimHawk 07:49, 25 November 2008 (UTC)

• No, nothing more. If you want, you can send me the files (LocalSettings.php, rabcg.php and groups.php) and I'll see them. Delete all private information. --Lodopidolo 08:29, 25 November 2008 (UTC)

Solution:

• There was blank spaces before <?php Tag.

This Error Occurs During Execution. Any one can tell me about this error.

Warning: Cannot modify header information - headers already sent by (output started at /home/skippers/public_html/includes/DefaultSettings.php:1) in /home/skippers/public_html/includes/WebResponse.php on line 16

Error: array_key_exists()

• Hi, followed your installation instructions and get the following error repeated 30 odd times at the top of every wiki page:

  Warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in 
  /var/lib/mediawiki/extensions/rabcg/rabcg.php on line 41

Cheers

Trace:

• How many times have you declared groups array variables? If you declare it in groups.php you must not declare anyone in rabcg.php and viceversa. Can you tell me more?

Solution:

• Solved. --Lodopidolo 09:51, 26 November 2008 (UTC)

Error on login

• I have the Special:UserLogin page in the whitelist array, but I cannot access it while browsing as anon. Any ideas? -Tom

Trace:

• Mediawiki is case sensivity. I think the problem is that correct name (of the page) is Special:Userlogin. Please, try this and tell me more. --Lodopidolo 16:52, 24 December 2008 (UTC)

Solution:

• Solved. Perhaps there wasn't any error. --Lodopidolo 22:23, 15 January 2009 (UTC)

Solution: I faced the same problem last week.

In fact, the name of the pages listed is not the same as the page's name so if the title is Spécial:Connexion (My wiki is in French) in the list, I have Special:Connect, so it cannot work. I perform the following modification to solve this issue: In the rabcg.php file, I add the line:

$testor = substr($title,9);//To avoir the special caracter issue (french é)
// and modify the wgWhitelistRead test:
if (isset($wgWhitelistRead[0])) 
{
 $pagBlanca = in_array($testor, $wgWhitelistRead);
}

Then, in the DefaultSetting.php file, I just use the french name (title) of the page to login £$WhitelistRead = array ("Connexion");

Can't edit user groups

• All the groups I try to add the user to as admin it wont save the custom groups :( everything else works fine why wont it save my user group permissions.

• Looks like you can edit groups but they are limited to 16 Characters, i have changed the restriction in the database anyone know where it is in the code ? still wont work.

Trace:

• I don't understand you. Please, explain me what is the problem. Groups must be added in your groups.php file. After you must assign that group to a document as a category name. --Lodopidolo 22:33, 15 January 2009 (UTC)

I have a same problem. adding to group is not save 95.90.246.17 16:29, 22 January 2023 (UTC)

Solution:

• Perhaps there wasn't any problem. Nobody contacts. --Lodopidolo 16:05, 29 January 2009 (UTC)

Anonymous Acces to public doc

• I would like to enable anonymous users to read all public articles. I tried a little bit with $wgGroupPermissions, but couldn't figure it out. Is ther any somehow not too difficult mod for this?

greets --Malte Mertz 15:25, 19 February 2009 (UTC)

Trace:

• You have two options:
  • You can put all public page you want to access by anonymous user as White pages. In this case all white pages are accessed by every body.
  • You can modify your $IP/extensions/rabcg/rabcg.php, where put:

else if (($user->isLoggedIn() && $categoriaValida) || $pagBlanca)

by:

else if (($categoriaValida) || $pagBlanca)

Try this and tell me if this is correct. --Lodopidolo 17:18, 19 February 2009 (UTC)

Yeah, it works, very cool. Muchas gracias!--Malte Mertz 16:26, 26 February 2009 (UTC)

• This was very useful tip as the main need is to restrict just some pages :D Thanks a lot! --Teemuo 07:01, 31 July 2009 (UTC)

This one worked perfect for me. Now all pages are visible to anonymous until they are part of the category i specified in groups.php. It would also be nice, to turn the feature around: only pages of a specific category can be viewed by anonymous. I changed the true and false values in the above mentioned part of rabcg.php, but then, all special pages are blocked, because they are not member of the specified category. --93.122.72.90 09:51, 1 December 2010 (UTC)

• I want to create a Category for all register users, that is the group 'Users', but it won't let me add it to groups.php without it creating a second group called Users when one already exists, and when I just specify [[Category:Users]] in an article it is open to anyone not logged in.--404Science 19:08, 4 February 2011 (UTC)

Can't Assign Right to User

The extension loaded properly, but the wiki won't save any changes when I try to assign the right to a user. Below is my only line in the groups.php file:

$wgGroupPermissions['Private Data']['private'] = true;

Using 1.13.3 --Leoottawa 22:19, 9 March 2009 (UTC)

Update

Looks like the problem is with spaces. I was able to assign the group PrivateData to a user. --Leoottawa 22:25, 9 March 2009 (UTC)

same here

I too have the same problem with group names containing spaces. It doesn't work with spaces, but works without.

Preventing public adding a page to private category

• Is there a way to prevent anonymous editors adding a page to a private category? -- Anon., 17:05, 22 March 2009 (UTC)

• • I'm no expert on the issue but I think that would require a lot more complex hack to the mediawiki.. Not sure though. --Teemuo 08:43, 31 July 2009 (UTC)

Usergroups loosing members

I have added line to groups.php

$wgGroupPermissions['RestrictedGroup']['private'] = true;

And I have also used the change in topic Anonymous Access to public doc.

The group keeps loosing its members at random intervals - when I log in as admin - I see only the group but no members attached to it.

I'm also using the Extension:LDAP_Authentication -plug-in - should that make any difference.

Any idea why the users lose their membership?

Trace:

• Hi, I don't understand you. I am usign Extension:LDAP_Authentication extension too and I haven't any problem with Extension:Restrict_access_by_category_and_group. Please, explain me more. --Lodopidolo 11:46, 14 September 2009 (UTC)

Mr.Montesa:

• Hello, I do have the same problems on my newly installed Wiki (15.1). I'm using the Extension:LDAP_Authentication extension too, but I don't think that it interacts with that problem. Local users loose their membership too. Here's my setup.

I want to prevent users from seeing some pages with confidential content by categories. A page disabled is added to category: CONFIDENT. groups.php's content:

$wgGroupPermissions['CONFIDENT']['private'] = true;

Then, I configured a user via Special:UserRights to be member of the CONFIDENT group by ticking the box and saved.

After logging out the user and relogging in, I'm not longer able to view the pages with category CONFIDENT. Checking the user I see that the box is unticked again.

If you need further details, let me know. --Mr.Montesa 11:43, 26 Oktober 2009

Not working in mediawiki 1.15.1

Here is my groups.php:

<?php
$wgGroupPermissions['TestPrivateGroup']['private'] = true;

Here is version info:

MediaWiki	1.15.1

PHP	5.2.6 (apache2handler)

MySQL	5.0.6

Here's my problem:

I have added a user to the TestPrivateGroup group via the user rights management 'special page'. I have created a page with

[[Category:TestPrivateGroup]]

at the bottom, yet there are no restrictions on access, everyone can see the page, even not logged in users. Am I doing anything wrong or does this not work in the latest version of MediaWiki. Thanks. 08:10, 13 October 2009 (UTC)

Confidential pages of several levels

To optimize the confidential pages of several levels. --PiFi 12:12, 28 February 2010 (UTC)

$IP/extensions/rabcg/rabcg.php

<?php

$wgExtensionCredits['parserhook'][] = array(
       'name' => 'Restrict access by category and group',
       'author' =>'Andres Orencio Ramirez Perez & Vadim Ispenkov',
       'url' => 'http://www.mediawiki.org/wiki/Extension:Restrict_access_by_category_and_group',
       'description' => 'Restrict access to pages by users groups and documents categories',
        'version' => 1.01
       );

function userCanGrupoCategoria($title, $user, $action, $result) {
	global $wgGroupPermissions;
	global $wgWhitelistRead;
	global $wgLang;

	$catnom = $wgLang->getNsText ( NS_CATEGORY );
	$tip_1 = false; // white page
	$tip_2 = false; // not permission
	$tip_3 = false; // permission one, open if not "confid category" on page
	$tip_3_open = false;  //close on default
	$tip_4 = false; // confid - all permission
	$tip_4_open = true; // open on default.
	// Is this page a white page?
	if (isset($wgWhitelistRead[0])) {
		$tip_1 = in_array($title, $wgWhitelistRead);
	}
		if (count($title->getParentCategories()) == 0)
                $tip_2 = true;
        else {
		// If document has categories, we see each one.
				foreach( $wgGroupPermissions as $key => $value ) {
                        //is a group like category,
                        if ((array_key_exists(strtolower($catnom.":".
                            str_replace(" ", "_", $key)), array_change_key_case($title->getParentCategories(), CASE_LOWER)))) {
                            	if (isset($wgGroupPermissions[$key]['confid'])) {
                                	$tip_4 = true; //$wgGroupPermissions[$key]['confid']; // =true  if is a private
                                	if (!(in_array($key, $user->getGroups())))
                                		$tip_4_open = false;	// close is a one of user permission of not being category in title
                             	} else {
                                	$tip_3 = true;
                                	if (in_array($key, $user->getGroups()))
                                		$tip_3_open = true; // open is a one of user permission of being category in title
                        		}
                        }
                }
                if ((!$tip_3) && (!$tip_4))
                	$tip_2 = true;
        }
        //open or close page
        if ($tip_1)
        		$result = true;

        else if ($tip_2)
                $result = true;

        else if (($tip_3) && ($tip_3_open))
                $result = true;

		else
                $result = false;

     	if (($tip_4) && ($tip_4_open))
                $result = true;

        else if (($tip_4) && (!$tip_4_open))
                $result = false;

        return $result;
}
$wgHooks['userCan'][] = 'userCanGrupoCategoria';
require_once "$IP/extensions/rabcg/groups.php";

$IP/extensions/rabcg/groups.php

<?php

// Level 1
// This is a pages in $wgWhitelistRead = array(' in LocalSettings.php

// Level 2
// It a pages with category, but it category does not in this file. Can be accessed.

// Level 3
// Can be accessed, if user belong to at least one of these groups.
$wgGroupPermissions['Conf1']['*'] = true;

// Level 4
// Can be accessed, if user belong to all least of these groups = category on the document.
// Not enough to have a level 3 to view these pages.
$wgGroupPermissions['Conf2']['confid'] = true;
$wgGroupPermissions['Conf3']['confid'] = true;
$wgGroupPermissions['Conf4']['confid'] = true;

does not work with files

This does not work with files. If they are closed category, but you can get them using the media:

I've noticed this as well.. however, it should be relatively straight-forward to extend the permissions to the img_auth.php script .. I added a topic here on this issues exactly and will comment here as well if/when I figure out how to do this (note - I am not the author. 'm a user of this extension like you) -- User:revansx

Can't log in.

I followed your instructions, but I can't log in. I even tried adding both "Special:UserLogin" and "Special:Userlogin" to the array added to LocalSettings, to no avail:

[url]/wiki/index.php?title=Special:UserLogin

Help?

See $wgWhitelistRead = array(' in LocalSettings.php --PiFi 19:02, 10 November 2010 (UTC)

Trace:

• Can you explanin any more? You have added Special:UserLogin to $wgWhitelistRead array in LocalSettings.php. Doesn't open login page?

--Lodopidolo 08:42, 12 November 2010 (UTC)

Comment this extension on LocalSetting and login. Then see $wgGroupPermissions --PiFi 09:04, 12 November 2010 (UTC)

Blank spaces at category on groups.php not works

Today, I try this extensions. I found that blank space when you write category in groups.php doesn't work. example :

$wgGroupPermissions['Templat Hadits']['*'] = true; 

"Templat Hadits" groups will show at Special:UserRight, but you will not be able to choose it. To solve this problem, you should add underscore (_) between two or more words, not a blank space.

Make it :

$wgGroupPermissions['Templat_Hadits']['*'] = true; 

and now you can choose "Templat Hadits" groups at Special:UserRight.

Broke no read access setting

Hi,

I installed this extension today, and it works great, except I kept my wiki locked down so that only people logged in can read the content here is the config I have for this:

# Try to ensure that people are logged in before they can read/edit/write.
$wgGroupPermissions['*']['edit'] = false;
$wgWhitelistRead = array( "Special:Userlogin");
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['*']['createaccount'] = false;
$wgRawHtml = true;

When adding the include line for this extension, it breaks the $wgGroupPermissions['*']['read'] = false; and now my wiki is wide open to be read by anybody.. How can I fix this?

Thanks.

Same here on MW 1.16.2 - when extension is enabled, the wiki is readable by everyone dispite $wgGroupPermissions['*']['read'] = false; -- 11:48, 18 March 2011 (UTC)

The wiki is not complete open. only the follow Namespaces are open: Categorie, Main and Template. User, wikimedia, localwiki, special are closed. Sometimes the wiki close after jump through some pages. --77.64.194.173 23:50, 4 April 2011 (UTC)

I "fixed" this by changing the following in the code. It now enforces users to be logged in, in order to see pages that aren't whitelisted.

...
	if (!$user->isLoggedIn() && !$pagBlanca)
		$result = false;
        // If groups don't exists and it isn't white page and doc has categories, this doc is a plublic doc.
        else if ((! $existeGrupo) && (! $pagBlanca) && ($docPoseeCategorias))
                $result = true;
...

--Hchasqueira 11:01, 16 May 2011 (UTC)

This "fix" does not work for me on Mediawiki version 1.20.6. The issue is that the Main Page is white-listed. So in ./extension/rabcg/rabcg.php, in the end of the file, we should remove or comment these lines: if ($wgVersion >= '1.17') {

 $wgWhitelistRead[] = wfMessage('mainpage')->plain();

} else {

 $wgWhitelistRead[] = wfMsgForContent('mainpage');

}

--Namtor 09 September 2013

White lists not working..

I think the code that checks if a page is on the white list or not is broken. At least in newer versions of wikimedia..

if (isset($wgWhitelistRead[0])) {
                $pagBlanca = in_array($title, $wgWhitelistRead);
        }

This is treating $title as a variable, when in fact it is an object. Shouldn't it be testing against $title->mTextform or something like that? I'm not a wiki programmer, but I modified the code to work this way and it fixed my problems (See my previous post).

How do you fix this?

Can you show us what code you used? I am having the same problem but can't seem to fix it.

If a page has no categories on it, then the extension correctly checks the whitelist and blocks anonymous people from accessing it. However if any category at all has been added, a non-restricted category, then it makes that page public, over-riding the whitelist. Any ideas?

Customise Permission Error message?

When a user has been denied access to page, it always comes up with the same message "The action you have requested is limited to users in the group: Users" but I think this wording is confusing. Should it say "the action you have requested is prohibited to users in your group" or should it be "the action you have requested is limited to users in the group: Permittedgroup" i.e. the last word should change to show the group permitted to access the page?

How can I edit this message?

• You can modify access error messages from your Special:Allmessages document: Special:Allmessages, concretely MediaWiki:Badaccess-groups.

--Lodopidolo 07:39, 11 April 2011 (UTC)

Looks like the System Message is "MediaWiki:Badaccess-group0" now rather than "MediaWiki:Badaccess-groups" for whatever reason.

--User:Revansx

Temporarily disable this plugin

I am trying to figure out if this plugin is causing some issue with password resets and would like to disable it temporarily, with the option of reactivating it without data loss in the future. What is the safest way to deactivate and then reactivate the plugin?

Also, has anyone else experience issues with password resets not working?

Leirith 04:43, 2 March 2011 (UTC)

• If you comment this line, you deactive this:

// $wgHooks['userCan'][] = 'userCanGrupoCategoria';
</source>
:--[[User:Lodopidolo|Lodopidolo]] 07:43, 11 April 2011 (UTC)
===Reset Password===
I had problems with password resets, too. To make it work, you'll have to add the page to the whitelist:
<source lang='php'>
function userCanGrupoCategoriaInitialize() {
  //[...]
  $wgWhitelistRead[] = $wgContLang->specialPage('ChangePassword');
  //[...]
}

But this leads to a problem in the check. If the name contains multiple words $wgContLang->specialPage() will use underscores for this. $title(.toString()) will use spaces. So the page is not accessible. To solve this you can compare to the prefixedDBkey:

function userCanGrupoCategoria($title, $user, $action, $result) {
  //[...]
  // Is this page a white page?
  if (isset($wgWhitelistRead[0])) {
    $pagBlanca = in_array($title->getPrefixedDBkey(), $wgWhitelistRead);
  } 
  //[...]
}

--(not logged in) 14:22, 6 December 2012 (UTC)

Allow administrator users to access any category by default?

If a user is an admin, I want them to always have access to any newly created categories without having to manually assign user rights to each admin user any time a new category is created. How can I achieve this?

Edit: NM I got this by adding the following at line 50 in rabcg.php:

                               else if ((in_array('sysop', $user->getGroups()))) {
                                       $categoriaValida = true;
                               }

White pages in French (français)

• Hi there.

I have a question about adapting your extension to a french wiki. You mentioned in the document so change Special:UserLogin to the appropriate language however when I do so , Special becomes Spécial:Connexion and is never works. Whether I use the accent or remove it or remove the capitals it doesnt work. If I switch the wiki to english it works right perfectly. Is there anything you can do to help?

Thanks in advance

Micah

Trace:

Check in your $MEDIAWIKI_INSTALLATION/languages/messages/MesagesFr.php for:

$namespaceNames -> NS_SPECIAL.

$specialPageAliases -> 'UserLogin'.

It appear to be: Spécial:Connexion, Spécial:Identification

You should put main page too: Accueil.

$wgWhitelistRead = array('Spécial:Connexion', 'Spécial:Identification', 'Accueil');

Regards. --Lodopidolo 12:19, 10 August 2011 (UTC)

Security hole: User language settings

I installed the extension as described. As long as the user´s language setting matches the LocalSettings.php $wgLanguageCode variable language, the access is restricted ok. However, if the user changes the displayed language under his preference, to anything different than $wgLanguageCode, then access is not restricted.

• Thanks for your observation. This security hole has been solved with this new version 1.02. It would be good idea if somebody more could probe it. I think all language problems must be solved. The problem was the $catman variable, which is dependent on user language settings.

--Lodopidolo 11:59, 20 January 2012 (UTC)

v: 1.02

Solved this Security hole: User language settings. --Lodopidolo 12:03, 20 January 2012 (UTC)

No difference between "no public" and "private" groups?

My understanding is that if a page has several "no public" categories, then user needs membership in only one such category to view page. If page has several "private" categories, then user must be member of ALL those private categories. But in my testing of current version 1.02, both categories behave the same. That is, a user that is member only of private1 can view a page that is in categories private1, private2, and private3. --Goadeff (talk) 22:58, 4 June 2012 (UTC)

trace

I feel the confusion of explanation. I've amended.

See: Configuration Example.

--Lodopidolo (talk) 11:11, 5 June 2012 (UTC)

v: 1.03

Version 1.03 has been released. It try to corrects some problems namespaces in differents languages. --Lodopidolo (talk) 11:22, 5 June 2012 (UTC)

$wgAutopromote and Extension not working?

I have set up $wgAutopromote to automatically set their group to my Private_Information group (made by Extension), and it SAYS it is working in the User Rights Management, however, when a user who has been automatically added to the group this way, it will still not allow them to view pages associated with that content.

EDIT: It says they're "Implicitly" a member of the group, but the box isn't checked due to how Autopromote works.

Bug or working as intended? This a pretty crucial feature for my community :)

Trace

This extension is based in $user->getGroups(). This means that a user must belongs to a group, and this is normally set in Special:UserRights.

Autopromote extension, as you can read in its page:

Autopromotion doesn't actually add users to a group;
MediaWiki will check whether a user meets the conditions for autopromotion whenever 
it checks the user's rights or effective groups. This means that a user will only appear
to be in a group on Special:ListUsers if they were added to it
through Special:UserRights.

So, although a user can be autopromoted, that user doesn't belong to that group, and then can't see those pages.

If you want, you can propose a change in this code to allow it and send us to incorporate in the extension.

--Lodopidolo (talk) 08:13, 12 August 2012 (UTC)

I did some research and made a change in the extension code:

//We see that the user belongs to one of the groups (like of category)
if ( in_array( $key, $user->getGroups() ) and ( !$privateCategory or ( $privateCategoryTemp and $privateCategory ) ) ) {
        $validCategory = true;
}
if (in_array( $key, $user->getAutomaticGroups() ) and ( !$privateCategory or ( $privateCategoryTemp and $privateCategory ) ) ){
        $validCategory = true;
}
$groupExists = true;

I added the if(in_array($key, $user->getAutomaticGroups())... tested it and it works fine! SjoerdFurth (talk) 23:00, 20 November 2014 (UTC)

Read Privilege

Hi, First of all thanks for the extension, its very useful. I'm with a doubt, I created a private group, and set users "A" and "B" to this group. Is there a way to a user "C" that not belongs to the private group, read a document in the private group?

Thanks!

Trace

With the actual development, it isn't possible. This extension is based on the access or not to the document. It doesn't provide read or write restrictions if the access is granted.

If you want, you can extend this functionality, and publish it here.

--Lodopidolo (talk) 09:57, 17 October 2012 (UTC)

Would it be easy to revote read privileges for pages that are restricted by this extension?

RecentChanges

Hi, after installing the extension the content of private pages can still be read through "RecentChanges". Does anyone know of a "simple" solution to block access to "Special:RecentChanges"?
Thx Marc

---

$wgWhitelistRead = array('Special:UserLogin'); Blanks out wiki

When attempting to implement the extension, the following line of text causes my entire wiki to return a blank page with nothing in it.

$wgWhitelistRead = array('Special:UserLogin');

Here are the version I'm using: MediaWiki 1.22.2 PHP 5.3.10-1ubuntu3.11 (apache2handler) MySQL 5.5.35-0ubuntu0.12.04.2 Lua 5.1.5 Any suggestions would be appreciated!--173.165.252.49 16:46, 12 June 2014 (UTC)

Access Issues

Hi all. Here is my problem :

I have created two user groups :

- (Group) named A - (Group) named B

I have assigned Category A and Category B to a page, but only user Group A is able to access the page... If i login as Group B user, i get the permission error message.

I have included the categories in groups.php:

$wgGroupPermissions['A']['*'] = true; $wgGroupPermissions['B']['*']= true;

Ultimately what i want to achieve is :

Create two user groups (A,B) User Group A must be able to access only pages that belong to Category A User Group B must be able to access only pages that belong to Category B

Both Groups must be able to access pages that belong to both Categories A and B

Thank you

Confirmemail Link won't work

When I click the link in the confirmation email, then I get a permission error.

The link is a subpage from "Specia:ConfirmEmail/....."

$wgWhitelistRead = array( "Hauptseite" , "Special:ConfirmEmail*" , "Spezial:Passwort_neu_vergeben" , "Spezial:E-Mail_bestätigen" , "Special:ConfirmEmail" , "Spezial:Abmelden" , "Spezial:Einstellungen" , "Benutzer_Diskussion" );
require_once "$IP/extensions/RestrictAccessByCategoryAndGroup/RestrictAccessByCategoryAndGroup.php";

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

$wgGroupPermissions['autoconfirmed']['read']                    = false;                       
$wgGroupPermissions['autoconfirmed']['mf-uploadbutton']         = false;
$wgGroupPermissions['autoconfirmed']['transcode-reset']         = false;
$wgGroupPermissions['autoconfirmed']['editsemiprotected']       = false;

$wgAutopromote['emailconfirmed']                                = APCOND_EMAILCONFIRMED;   
$wgImplicitGroups[]                                             = 'emailconfirmed';        
$wgGroupPermissions['emailconfirmed']['read']                   = true;

Ok, here is my solution.

I add in line 30:

$wgWhitelistRead[] = $wgContLang->specialPage( 'ConfirmEmail' );

I added/changes something at line 47 (46):

	//Is this page a white page?
	if ( isset( $wgWhitelistRead[0] ) ) {
		if ( strstr( $title , "/" , true ) ) {
			$whitePage = in_array( strstr( $title , "/" , true ) , $wgWhitelistRead );
		} else {
			$whitePage = in_array( $title , $wgWhitelistRead );
		}
		$wgGroupPermissions['autoconfirmed']['read'] = true;
	}

Allow Access by Category?

Is there a way to have a Category called Public and allow someone not logged in to view any pages with that category, but restrict them from viewing pages that do not have that category?

What about img_auth.php?

I'm testing this extension on my 1.30 wiki and it seems to work well. However, when I add an upload file to the protected category, the file's wiki page is protected as expected but the link to the actual file is not. I am configured using the "img_auth.php" script[1], but the read restriction doesn't seem to propagate into the img_auth script. I've tried clearing the cache in case that was the issue. So is this expected behavior for this extension? Am I missing something? Thanks! --User:revansx

I made the following hack: Extension:Restrict access by category and group/with img auth support.
It works to extend the protection to the "current version" of the file through img_auth.php, however, archived versions of the file are still accessible to anyone who knows the links. I will attempt to figure out how to close this security hole and update this reply when done.

trace

Feel free to modify/extend it.

Regards. Lodopidolo (talk) 13:57, 30 September 2019 (UTC)

Compatibility >= MW 1.36

Starting from MW 1.36:

The confusingly-named User->isLoggedIn() method has been deprecated in favour of the method it wraps, User->isRegistered().

Quick Fix:

Replace

 if ( ( $user->isLoggedIn() and $validCategory ) or $whitePage ) { 

with

 if ( ( $user->isRegistered() and $validCategory ) or $whitePage ) { 

Michele.Fella (talk) 21:00, 15 February 2023 (UTC)

Thanks!

I also had to change the $wgHooks['userCan'][] = ... to $wgHooks['getUserPermissionsErrors'[] = ... for to it function on my 1.39

77.111.214.110 08:37, 14 March 2023 (UTC)

MV 1.40

I recently upgraded to MediaWiki version 1.40.1, and RABCAG no longer works at all. Every page marked for no public access or private access is now fully visible to the public. My version page shows that the extension is installed, and I've updated my extension php files with the latest code from this page. It's not generating an error, it's just not hiding private pages from the general public. Has anyone else upgraded to 1.40 and seen a similar issue? --TheAlmightyGuru (talk) 14:08, 18 October 2023 (UTC)

Yes!

I need to make two edit :

function restrictAccessByCategoryAndGroup( $title, $user, $action, &$result )

and adding $result = false; before return false; 192.134.133.9 16:25, 28 November 2023 (UTC)

User::getGroups was deprecated in MediaWiki 1.35

AH01071: Got error 'PHP message: PHP Deprecated: Use of MediaWiki\\User\\User::getGroups was deprecated in MediaWiki 1.35. [Called from restrictAccessByCategoryAndGroup in /mediawiki/extensions/RestrictAccessByCategoryAndGroup/RestrictAccessByCategoryAndGroup.php at line 74] in /mediawiki/includes/debug/MWDebug.php on line 386'

extensions/RestrictAccessByCategoryAndGroup/RestrictAccessByCategoryAndGroup.php
Ligne 74 :
if ( in_array( $key, $user->getGroups() ) and ( !$privateCategory or ( $privateCategoryTemp and $privateCategory ) ) ) {
...

Remplacer getGroups() par getEffectiveGroups() 
La page ne s'affiche plus :
MediaWiki internal error.

Une idée pour résoudre l'erreur AH01071 ?