Version 0.7 of AccessControl Extension for MediaWiki

Friday, January 12. 2007

Version 0.7 of AccessControl Extension for MediaWiki

another Version with new features is out.

the extension can be downloaded under http://www.pagansoft.de/download/accesscontrol-0.7.zip

read on for details

Changes:

now it's possible to have read-only groups.

the english language is set as default

refactored some functions for better readability

it's now possible to use the internal groups from MediaWiki

There are some thing to to for the next version::

Restrict search/RSS results for protected pages (without pathich if possible)

the use of multiple accesscontrol-tags for use in templates

the additional use of single users

the accesscontrol-tag has to be on the first line of the wikitext to work correctly, that has to be fixed

My original article with the last version can be found here

The previous version can be found here.

Posted by Martin Gondermann in Eigene Software-Projekte at 14:28 | Comments (64)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

still bugged with wikimedia 1.9 it seems.

I get something like this on top of protected pages:

UNIQ12f64d5f3e553d12-accesscontrol-00000001-QINU Test de page restreinte

#1 lan (Homepage) on 2007-01-15 17:26

The problem seems to come from the function "displayGroups" which builds a string transmited to the $wgOut->parse() function.

To fix the bug, suppress the call to $wgOut->parse(), that is replace

return( $wgOut->parse($style.sprintf($wgGroupLineText, $displayGroups).$style_end) );

by
return $style.sprintf($wgGroupLineText, $displayGroups).$style_end;

and

return( $wgOut->parse($style.sprintf($wgGroupsLineText, $displayGroups).$style_end) );

by
return $style.sprintf($wgGroupsLineText, $displayGroups).$style_end;

It seems that the call to wgOut->parse breaks the current parsing.

Note that you can personnalise the style here using $style and $style_end which can also be combined with css, for example:

$style="< span id=\"accesscontrol\" >"
$style_end="< /span >"

#1.1 Julien Allali (Homepage) on 2007-01-17 15:16

Alternatively, if you don't want the accessible groups to display anyway, you can just change $wgAccessControlDisableMessages to true in the accesscontrolSettings.php file. (It disables some capability, but is simpler if you don't need that capability)

#1.1.1 Mike Straw (Homepage) on 2007-02-03 16:55

if you don't use $wgOut->parse, the results won't print out the link but something like [[Usergroup:GroupName|GroupName]]

it doesn't solve the problem totally.

#1.1.2 chientai on 2007-05-08 10:55

I tried what you recommended but nothing was changed. My MediaWiki version is 1.9.1. Thank you.

#1.1.3 Sacip on 2007-06-22 18:47

You have to resave the Page with the ""-tags. Mediawiki only parses the syntax one time and when you change the php-code nothing changes in the Articleuntil you save it and it is reparsed. It took me some hours to figure this out too.

#1.1.3.1 Max (Homepage) on 2007-07-18 17:14

Just edit the accesscontrol.php in the displayGroups-function and change the two lines with

$wgOut->parse(..);

to

$wgOut->addWikiText(...);

(had the same problem with 1.10.1 and this solved it for me.)

#1.1.4 raZe (Homepage) on 2007-09-07 10:10

I attempted to install this for MW 1.6.9

All other instructions being followed, when I uploaded the new LocalSettings file, the wiki totally stopped functioning... just whitespace presented.

#2 Randy on 2007-01-15 20:03

What Ian said is supposed to happen or it is really a bug with mediawiki 1.9?
Is it possible to specify a wildcard to match all/rest of the people? To be more clear, it would be useful something like this Managers,*(ro) instead of adding all people to a generic group?

#3 Andrei on 2007-01-19 10:03

I'm seeing nothing but blank pages when I install this under mediawiki 1.9. Any ideas?

#4 Scott on 2007-01-26 00:35

Sorry to all, but I haven't testet the extension on MediaWiki 1.9 yet. 1.8.2 is the last version I personally run. I have to upgrade first. Sorry for any inconvenience.

#5 MagicMonty (Homepage) on 2007-01-26 16:54

I have upgraded from MW 1.4.2 to MW 1.9.0 and also installed accesscontrol 0.7 + minor modification posted above by Julien. Everything works fine.

#5.1 Andrei on 2007-01-27 01:18

I noticed a bug: as mentioned in the docs, ordinary users can't view/edit usergroup pages, but they aren't prevented from creating them. Surely this shouldn't be allowed?

#6 Paul Eggleton on 2007-01-29 02:33

I've got another bug: on MediaWiki 1.9.0 with AccessControl all text maked with text is listed as
UNIQ1f3b315c3b479da4-pre-00000004-QINU
The server was updated from php-4.1.3 to php-5.1.6
The lines mentioned by Julien Allali were updated.

#7 Andrei on 2007-01-29 09:13

Discard last post. It seems that MediaWiki 1.9.0 inherited bug 8451 from version 1.8.2

#8 Andrei on 2007-01-29 09:33

Hi,
I've installed accesscontrol 0.7 with MW 1.8.2 on Windows 2k3. When I add require_once("extensions/accesscontrolSettings.php");
to my LocalSettings.php the wiki no longer loads. As soon as I comment out that line everything loads properly again...any idea what is causing this and how I solve it?

Thanks

#9 Dylan on 2007-01-31 20:05

Hi! I am looking to provide our Wiki with this AccessControl feature. It looks exactly what we need. We already have a Version 1.5.6, so I have to (first)update it to the 1.6. Will it work? Our PHP Engine Version is 4.3.9 (apache2hadler) and MySQL Version is 4.1.11-Max-log. I am afraid we cannot change these Versions (IT-Problem). Will it work only if we Change the Version of Wiki? Thanks a lot for your help

#10 Marta on 2007-02-02 15:51

I think it should work on MediaWiki 1.6 and up. I haven't tested the actual version on 1.6 but I left the option for 1.6 in. This extension depends not on the MySQL version or the PHP version. Just try it. If it not works, please tell me, I will try to fix it.

#10.1 MagicMonty (Homepage) on 2007-02-02 18:59

It doesnt works with version below 1.7!
With MW 1.6.9 you get an error like
"accesscontrol.php on line 115" bla. Version 0.6 works fine with MW 1.6!

#10.1.1 Ben on 2007-02-14 09:12

I would like to do this too. Has anyone figured out if this is possible?

Cheers,
Andy

#10.1.1.1 Andy Thornton on 2007-03-03 21:13

The extensions works fine with 1.6.10 (version I have) if few changes are made:
1. When passing by reference (&$readOnly - second parameter in line 115) default value cannot be assigned, since object is supposed to exist already. I am puzzled why it works in PHP5. Sounds like a bug of PHP5
2. When calling that function (makeGroupTitle) all parameters must be explicitly set, i.e. before calling that function (place where it's called with one parameter) add something like:
$readOnly = false;
makeGroupTile(..., $readOnly);
Then it will work properly, including (ro) attribute. Please, notice that using "own" user groups is quite confusing. I personally prefer Group Admin extension and setting "$wgUseWikiGroups=true" (or whatever it's called) in accessControlSettings.php.

Let me know if you still have troubles with that.

#10.1.1.2 Shimon Pozin (Homepage) on 2007-04-02 15:10

Is there a way to give anonymous users read only access while controlling edit access to a specific group? I have pages that I want to restrict editing access, but allow anonymous users to still read. As soon as I add an accesscontrol tag, it turns off read-only access for anonymous users (I have not set read control in the LocalSettings file, so they can browse all other pagess).

Any suggestions?

#11 Mike Straw (Homepage) on 2007-02-03 17:08

Hello, you can do that adding a Anonymous group with Anonymous user, and changing line 278 from accesscontrol.php
change:
if (!in_array(strtolower(trim($wgUser->getName())), $allowedAccess))
for:
if (!in_array(strtolower(trim($wgUser->getName())), $allowedAccess) && !in_array(strtolower("Anonymous"), $allowedAccess))

then, you can make a page anonymous readonly by adding this between "accesscontrol" tags:
Anonymous(ro)

this is useful, for example, for the No_Access page.
Hope that it helps

Lluís

#11.1 Lluis Gili on 2007-04-27 10:28

hey martin,

thanks for your helpful script, but i've got a problem with it:

i use the version 1.6 of mediawiki (my server is still on php4) and your script throws an exception in line 115. i think the problem is the "&" in "&$readOnly = false". i've changed it into "$readOnly = false" but i miss still the read-only function, although i use the "(ro)".

do you have any idea what's wrong with it? thanks for your help in spe!

best regards,
kai

#12 Kai Mascher on 2007-02-05 19:20

You've got it wrong. Instead, remove "=false" part from line 115:
makeGroupTitle(..., &$readOnly)
Passing by reference does not assume default parameter, since object supposed to exist prior to call.

#12.1 Shimon Pozin (Homepage) on 2007-04-02 15:16

Hi!

I really like your accesscontroll-extension for mediawiki, but i'm kinda...ehm...missing a feature

Isn't it possible to allow specific usergroups (Usergroup:xxx) to view an entire category? so that i set the accesscontrol-thing inside the category and dont have to do this again for every page that's part of it? would be great (and 'd help keeping work minimalistic)

#13 Henning Buesch (Homepage) on 2007-02-12 10:58

Hi Monty,

it would be nice if the AccessControl feature would work with templates as well. Currently only the template itself is protected, but not a page that uses this template. Is that what you are reffering to in your todo-list?

Thanks for your great extension again!

#14 Sebastian on 2007-02-14 14:15

Hi,

My current MediaWiki (1.8.3) configuration requires user login and does not allow visitors to create accounts. I currently use 0.7 access control. I would like to change my configuration so that "visitors" can create or request valid accounts, and leave questions and comments on discussion pages only - similar to a BLOG I guess. I don't want spammers to vandalize my main pages. How would you approach this problem?

-Ron

#15 Ron Sheely (Homepage) on 2007-02-14 21:02

The issue with the UNIQ--- String seems to be a bug in MediaWiki 1.9 itself. As a workaround you should set temporarily $wgAccessControlDisableMessages to true.

Sorry for the inconvenience.

#16 MagicMonty (Homepage) on 2007-02-15 12:46

Your Extension don't block searching in a Page

#17 miki on 2007-02-21 13:47

I'm back again with another question and a possible answer.
I had UNIQ--- string problem because in php5 zend engine was set to work as in php4 (backward compatibility)
zend.ze1_compatibility_mode = On
If you set it to Off everything should work just fine.

Now, because I'm very lazy I have modified (using an sql update command) all old_text entries from text table to have on the first line an accesscontrol directive (except the Main Page). All worked well, but after few days on all edit tabs I get this text "group edit" instead of the usual title "edit". What can I do to remove the aditional text from edit tab?

#18 Andrei on 2007-02-22 13:38

A feature in the next version should also be a restriction in the image list (special pages). One can limit the control to the image description. Would be nice if the image would be excluded from image list then.

#19 Stephan on 2007-03-05 13:45

Another suggestion for the problem with uploaded files:
One could create .htaccess-files with random password for every uploaded file and include user/password in the url on the pages. One could save this information in the description page of the file.

#20 Stephan on 2007-03-05 13:53

I have another idea for extending the scheme:
It would be nice if one could write groups in an Usergroup page so that one can define an hierarchy (one group that includes one ore more other groups and some other users).

#21 Stephan on 2007-03-06 22:25

I just installed extension Version .7 on my mediawiki 1.9.3 and have found that my protected pages can be read but not edited by users listed in the selected usergroups. Does anyone know what might be causing this?

#21.1 Katie on 2007-06-19 04:44

Hi!
In my Installation (MW 1.6.9) the allowed groups are not displayed correctly. If there is more than one group, which has access rights to a page, only the last one in the row is displayed.
For example Test,Test1
displays "Diese Seite ist nur für die Gruppe(n) Test1 zugänglich."
Any suggestions?

Jérôme

#22 Jerome on 2007-03-14 14:53

Hi Martin. We needed some user and group page-per-page access control extension, so I added the user capability in accesscontrol 0.7. I didn't had time to look at the mediawiki 1.9 parser bug

You'll find the package at http://binfo01.iric.ca/~larosem/accesscontrol-0.7.1.tar.gz

#23 Martin Larose on 2007-03-14 20:00

Slight problem.
No matter who you add to a group, whenever I limit the access to the group, noone can access it only the sysop.

What can be the problme?
I use the UserGroup:groupname pages,
I put in the Real name of the user, the login name of the user, but still, it does not work.

I use MediaWiki 1.9

What should I do so people could actually access the pages?

#24 Roland Hesz on 2007-03-20 16:45

AllUsers dummy page, user access to Usergroup:User page

I wanted to be able to have users specify who has write access to their pages (if they so choose). Problem is that the accesscontrol mechanism easily allows write access but not read access to all users. A user may, of course, create a Usergroup:MyListOfUsers page and add MyListOfUsers(ro) to the accesscontrol tag but this doesn't allow anonymous read access, and it is a maintenance problem to keep the list of users up-to-date.

I've modified this extension to recognize an "AllUsers" entry in the access control tag. There is no page associated with this entry. An entry of "AllUsers" allows read/write access to everybody. More useful is that "AllUsers(ro)" will allow read access to everybody.

An associated necessary modification is to always allow every user to be able to have write access to their *Usergroup:Username" page.

In this way a user may choose to allow everybody to see his page, but limit edit access to only those editors he chooses by providing an accesscontrol tag of "AllUsers(ro),,Username", and listing the editors in his Usergroup:Username page.

It has limits ... the user has access to only his one Usergroup:Username page. It would be nice to extend that somehow but for now, it works for me.

If there is interest, I can post my mods here.

#25 Joseph Michaud on 2007-04-10 22:59

This is exactly what I am looking for. I want to have an easy mechanism to protect pages and give that ability to users instead of me going in and protecting individual pages. Can you post the link to the updated extension? Thanks!

#25.1 Geoff on 2007-08-23 19:08

This is an interesting addition.

Could you post the modification?

I wish this would be included by default into this extension, because without having also an All users access control I find this extension a bit halfway there.

Also if you got this for 0.6 version, that one is more needed for myself. Can't use 0.7 as it doesn't work on my 1.6.10 mediawiki.

#25.2 Jukka Palko on 2007-09-04 14:19

I have set everything up according to the instructions and it seems to be behaving properly (ie the debug log says tht the user has been found and should be granted access) but I continually only get the No-Access page.? Anyone else run into this? Mediawiki 1.9.3

#26 Lloyd (Homepage) on 2007-04-26 22:51

FYI it seems I might have been mistaken. I was trying to be able to edit the Usergroup pages as a group member IT-Department but it was locking me out and I was assuming it was not working. It seems only the admin account can access the Usergroup pages.?. as access restrictions and group edit allows on other pages seem to work fine?
Is this normal behavior sir?

#27 Lloyd (Homepage) on 2007-04-26 23:18

Hi,

I am running the extension over MW 1.8.2. The extension is correctly controlling the access to the pages but the No_Access page is not called when the user is not allowed to view the page. Instead, the browser shows a message saying that the page does not exist.
What should I do, please ?

Thanks in advance

#28 Marcio on 2007-05-03 20:51

I have adapted this extension so that now it's possible that everybody, even anonymous users can read a page, but only allowed users can edit it.
If you are interest contact me.

#29 AlexUgarte on 2007-05-09 11:52

Hello,

Have installed the extension works great. Only when using the following wikicode in a blocked page it doesn't show the photo gallery!?

image:image1.jpg|
image:image2.jpg|

While in the rest of my Wiki with the none blocked pages it's does show correctly the photo gallery.

#30 Erik van Berkum (Homepage) on 2007-05-15 17:43

Thanks for this great extension - working fine on 1.8.3!
Any progress of the issue (with later versions) diplaying the hash (eg. UNIQ1f27a1bfec43e8c-accesscontrol-00000001-QINU ) instead of the expected text? I've tried the fixes suggested on this page and made some progress; the restriction message is appearing correctly now, but the actual content is still replaced with the hash. I'd really like to upgrade to 1.11.0, but I do need the accesscontrol extension! Any ideas? Thank you.

#30.1 Roy McMorran on 2007-09-20 17:14

I made the change recommended above and continued to get the UNIQ string problem. To get the page to render properly, I just edited the wiki page and saved. Then the restriction message appears correctly. Using mediawiki 1.9.3 and access control 0.7.

Thanks for your efforts, this is what we were looking for and was very simple to implement.

#31 Jim on 2007-05-19 02:06

There is a bug in the version-checking code in this extension. In at least one place, you check whether $wgWikiVersion >= 1.7, but this breaks for MediaWiki version 1.10 and above, since 1.10 is mathematically less than 1.7. Obviously this can be worked around by specifying $wgWikiVersion = 1.9 instead of 1.10 in the settings, but that's probably not desirable.

#32 Adam on 2007-05-24 16:30

I just want to protect the bages "user" based, besides "group" based. I´ve made some changes, it works, but it haven´t been tested right. Somewone have other extension that can do a SIMPLE USER BASED Protection?

#33 Tiago (Homepage) on 2007-06-06 15:42

I have installed the access control step by step, and the wiki works fine. However, when adding "testgroup" and then when I save, the page is displayed as "testgroup". So it does not work. Does this mean it is not reading the accesscontrol.php files? Any help would be appreciated.

#34 Marco Pretorius on 2007-06-13 14:23

Hallo,

ich hab ein Problem mit deiner Extension: Das AccessControl-Tag wird korrekt geladen, die Gruppen korrekt ausgelesen und dem Benutzer wird auch das Recht zum Betrachten gesetzt (access granted, user BLA is in group...). Der Benutzer bekommt dann aber aus irgend einem Grund trotzdem die Fehler-Seite angezeigt. Gibt es da bereits Ideen, woran das liegen kann?

#35 Mathias on 2007-06-20 11:37

First of all, congratulations for your work !

In debug, I see:
"getGroupsToDisplay_1: Extracted Group Title: MyGroupName"

But, I shall have:
"getGroupsToDisplay_1: Extracted Group Title: MyGroupName"

This problem due to function "hookUserCan". You must replace the line:
"$allowedGroups = str_replace("(ro)","",substr($content, $start, $end-strlen($endtag)+1 ));"
by:
"$allowedGroups = str_replace("(ro)","",substr($content, $start, $end-$start ));"

The last parameter is the lengh to save in the word $content.

#36 Bonnegent Sebastien (Homepage) on 2007-06-29 16:22

I seem to be having problems as well, when I use version 0.7 all I see is a blank page.. But when I use version 0.6 it seems to work fine.. The thing is I don't like having to use the pages for usergroups and would much rather prefer to use the wiki groups.. Also I am using version 1.6.10 as my host has not upgraded their PHP to 5.0.x yet..

#37 Aiden (Homepage) on 2007-07-01 18:26

I am new to MediaWiki and as a task at work I have to implement the following functionality:

1) a teacher can create groups and delete them

2) a teacher can add/remove students to groups

3) during assessment time, students from one group can not read nor write the work of students of the other group. The students work in groups, doing the collaborative translation

4) after the assessment time, students from one group can read the work of the other group, but no one can edit anymore their translation, as it is locked for editing

Can these functionalities be accomplished by your extension and how?

Thank you in advance for your help!

Regards,
Aleksandar

#38 Aleksandar on 2007-08-03 08:09

I stuck with this White-Page-Problem/Blank Page-Problem
(Ich bekomme ebenfalls weiße Seiten, wenn die Extension aktiviert ist)

Strange thing: It worked fine a while, suddenly, no more pages were delivered.
(Seltsam: Eine Weile ging die Extension super, plötzlich nicht mehr)

Could anyone solve this problem already?
(Hat das schon jeand gelöst)

#39 Bernd on 2007-09-12 09:33

There is a small patch for MediaWiki 1.11.0 - look at http://www.mediawiki.org/wiki/Extension_talk:Group_Based_Access_Control#Internal_server_error_in_MediaWiki_1.11.0

#40 ook on 2007-09-13 16:35

Hi ook

Sorry, but I don't know how to use the patch... I don't know what to change in the acesscontrol.php...

Matt

#40.1 Rmatt (Homepage) on 2007-09-24 12:29

Hi,
patched version: http://www.volny.cz/ook/accesscontrol.zip

ook

#40.1.1 ook on 2007-09-25 13:30

I installed MediaWiki 1.11.0 and get the following error when accessing:

"Internal Error
Detected bug in an extension! Hook, hookUserCan failed to return a value; should return true to continue hook processing or false to abort"

Commenting out the "include("extensions/accesscontrol.php"); line in LocalSettings.php makes MediaWiki function correctly.

I would appreciate any help regarding this difficulty. Thank you.

Chet

#41 Chet on 2007-09-18 16:24

Congratulations for the work Martin

This extension seems to be very very interesting, but I'm unable to make it run with my MediaWiki 1.11.0.
I tried the tweak and tips suggested, I always have this fatal error when loading the access control extension through the LocalSettings.php

You might try the plugin on this version and tell me if it is my fault or if there is an incompatibility

Regards,
Matthieu

#42 Rmatt on 2007-09-24 03:14

The patch at http://www.mediawiki.org/wiki/Extension_talk:Group_Based_Access_Control#Internal_server_error_in_MediaWiki_1.11.0 works.

I added to the original accesscontrol.php file the following:
(the line number is the added line)
Line 100
{
global $wgParser;
$wgParser->setHook( "accesscontrol", "doControlUserAccess";
return true; /*added line*/
}

Line 476
controlUserAccess( $allowedGroups, true);
}
}
}
return true; /*added*/
}

Line 551
}
else
return true;
return true; /*added*/
}

Thank you ook and whomever else for the help with this.

Chet

#42.1 Chet on 2007-09-26 20:19

I am also unable to get it working under version 1.11.0 the patches mentioned above do not work any more in this version.

I think we need an upgrade of the extension to make it work again.

#43 Erik van Berkum (Homepage) on 2007-09-24 16:36

I'm using "Short URL" and was having issues that whenever I was logged in as a user that was not a sysop, whenever I tried to access Usergroup:Groupname, I was getting a 404 error.

After several hours, I ended up replacing:

// redirect to the no-access-page if current user isn't a sysop
$wgOut->redirect($wgAccessControlNoAccessPage);

With just:

doRedirect();

Fixed the issue. However, I am still getting the 404 error whenever I search for a term that happens to be on a protect page, the wiki continues to give me the 404 error. Anyone know where the redirect is set for search terms in this extension?

#44 Marc on 2007-09-25 21:32

The author does not allow comments to this entry