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  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  tags in your LocalSettings.php? Nearly all LocalSettings.php files are . So you must put it between ". Therefore I've made a provisional one (?>) an I've put the line there after between "". 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: 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)


 * 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:
 * by:
 * Try this and tell me if this is correct. --Lodopidolo 17:18, 19 February 2009 (UTC)
 * Try this and tell me if this is correct. --Lodopidolo 17:18, 19 February 2009 (UTC)
 * 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  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 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)

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

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:

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:

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

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. --Hchasqueira 11:01, 16 May 2011 (UTC)

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)

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:
 * --Lodopidolo 07:43, 11 April 2011 (UTC)
 * --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: 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: --(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.


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

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)

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