Extension talk:PageProtection

I started a new page for the development of PageProtection: /Development. Ideas / Feature-Requests should be placed there.

Does it work with MediaWiki 1.6.7 or 1.6.8 or 1.8.0 ?
Thanks for a great extension! However, PageProtection does not seem to work after upgrade from MediaWiki 1.6.6 to 1.6.7 :(

Does anyone know of ways to make it work in 1.6.7 ?

Branch for 1.8.0
Hi, I've created a branch, which should resolve common CPU problems, but requires few more minutes to be installed properly. The branch is called PageProtectionPlus and uses symmetric ciphers combined with RSA encryption (near to technology applied in encrypted e-mail messages).

Siefca 16:39, 19 November 2006 (UTC)

Tarball for 1.8.0
Hi, I've applied all patches described here around and have added internationalisation support for PageProtection 1.4. It's also possible to create warning messages using wiki template pages. It's working very fine for me (except the known feature with the protected sections which causes whole page to be uneditable by unprivileged user).

Major change: the pathname of the PEM file – I've moved it to LocalSettings.php as $wgPEMfile variable for more clear setup for my collegues. Everything you'll need is described in INSTALL file.

My configuration is:


 * OS: RH enterprise 4u3
 * PHP 5.1.5 compiled as SO module (--with-gmp --with-bcmath --with-mysql)
 * Apache 2.2.3
 * php modules: Crypt_RSA 1.2.0b, PEAR 1.98

The PageProtection-1.4-2.tar.gz is available under:


 * ftp://ep09.pld-linux.org/people/siefca/software/
 * ftp://ftp.pld-linux.org/people/siefca/software/
 * http://ftp.pld-linux.org/people/siefca/software/

These links does not work for me, but have found this one:


 * http://ftp.icm.edu.pl/packages/linux-pld-linux/people/siefca/software/PageProtection-1.4-2.tar.gz

hope it will be useful, Siefca 19:08, 18 October 2006 (UTC)

Another problem
Hi! I installed MediaWiki 1.8.0 and PageProtection for 1.8.0. Mediawiki is starting normally, but when i want to edit a site, there is nothing displayed in the Browser (white site - no sourcecode in it).

In the ApacheLog there is 1 entry:

[Tue Nov 07 09:00:30 2006] [error] [client 139.25.163.172] PHP Notice: Only variable references should be returned by reference in /srv/www/htdocs/Crypt/RSA/MathLoader.php on line 106, referer: http://192.168.2.33/index.php/Hauptseite

What did i wrong?

OS: Suse Linux 10.1 Apache 2 PHP 5 with MySQL

I tried Crypt_RSA Version 1.0 and 1.2 - same Errormessage.

Thanks, Thomas

Same Problem
Hi.. Iam also having the same problem.Iam using Windows XP with Apache2 and PHP 5 with MySQL.Iam using MediaWiki 1.8.2.

Any help will be appreciated. Thanks,Deepak

Error in 1.6.7
After applying the Patch I get the following error message and it would be great, if somebody could help me with this:

Warning: Missing argument 2 for protectpage in ...\wiki\extensions\PageProtection\ProtectPage.php on line 31 Warning: Missing argument 3 for protectpage in ...\wiki\extensions\PageProtection\ProtectPage.php on line 31 Fatal error: Call to a member function on a non-object in ...\wiki\extensions\PageProtection\ProtectPage.php on line 32

My ProtectPage.php looks like this:

31: function protectPage($text, $params, &$parser) { 32:   $parser->disableCache; 33:   34:    global $wgUser; 35:   global $wgOut;

Powermax123 11:09, 5 November 2006 (UTC)

Try to install one of the:


 * bcmath extension (have to be enabled in php.ini)
 * PHP with GMP extension (http://www.swox.com/gmp/)

Siefca 16:35, 19 November 2006 (UTC)

Patch for 1.6.8
I patched PageProtection 1.4 to work with MediaWiki 1.6.8. The main problem was the changed data and array structure of the internal function extractTagsAndParams.

Additionally it changed some refereced variables, because &$variable is obsolete in php 4.3.10 and dont work in php5.

Next try, Patch updated should work now.

PageProtection/Patch_for_PageProtection1.4_and_MediaWiki1.6.8

User:Nimrodxx


 * It seems the patch for 1.6.8 prevents the PageProtection extension from working on my wiki. (MediaWiki: 1.6.8 / PHP: 4.4.1 (cgi) / MySQL: 4.1.19-standard) When trying to edit any page, the top of the edit page will produce the following error:

Warning: Missing argument 1 for protectpage in /...../public_html/wiki/extensions/PageProtection/ProtectPage.php on line 24


 * Line 24 is one of the changes made in the patch for 1.6.8: it used to be function ProtectPage { but was changed to function ProtectPage(&$parser) { in the patch for 1.6.8. (By the way, to spare anyone the effort to patch the 5 files, here is the patched package for 1.6.8 for download, 30 KB.)


 * Can Nimrodxx or anyone advise us on how to get around the Missing Argument issue in 1.6.8? Thank you.
 * --Faterson 10:35, 6 August 2006 (UTC)


 * To get around the problem, you can modify protectSave (modifications are in bold)

function protectSave(&$article, &$user, &$text, &$summary, &$minoredit, &$watchthis, &$sectionanchor) { //   die($text); global $wgParser; $protect = new ProtectPage($wgParser); $protect->mParser = new ProtectionParser($text, $protect->mEnc); $protect->mParser->parseText; $protect->encryptTags($text, $user->getName); return true; }


 * protectedEdit also needs a few changes:

function protectedEdit($editpage) { global $wgUser, $wgParser; $protect = new ProtectPage($wgParser); $protect->initEdit($editpage); if (!$protect->mParser->isProtected ) { return $editpage; }   if ($protect->mAccess->hasAccess($wgUser) ) { $editpage->mArticle->mContent = $protect->decryptPage; return true; } else { $err = new ErrorHandler($protect->mAccess, $wgParser); return $err->stopEditing; }   return false; }


 * Hope that helps! --Rico Nagtalon 22 September 2006

Changing Parser.php Fix
Error confirmed. You will get this error message on editing any page:

Warning: implode [function.implode]: Bad arguments in C:\Program Files\xampp\htdocs\wiki\includes\Parser.php on line 337

You will get it running on 1.6.7 only if you use an older parser.php, like 1.6.6.

220.233.191.237 03:24, 2 July 2006 (UTC) :


 * Thanks very much for proposing a fix.
 * However, 1.6.7 was supposed to close an |XSS Security Vulnerability in previous 1.6.x releases. Will dropping the parser.php to an older release (like 1.6.6) re-introduce the security hole that 1.6.7 was fixing ?


 * While I cannot definitely say, YES. &mdash; Ambush Commander (Talk) 23:48, 28 July 2006 (UTC)

You may download the older Parser.php from svn here: Parser.php version 1.6.6

--194.65.103.2 11:38, 11 August 2006 (UTC)


 * I have the same problem using MediaWiki 1.7.1
 * But I can't change Parser.php because MediaWiki stops working, with a message like

Fatal error: Call to undefined method Parser::firstCallInit in /var/www/htdocs/mediawiki-1.7.1/includes/MessageCache.php on line 528

Page errors on the top of page when EDITING pages
is anyone else having this problem? after installing PageProtection - i'm getting the following errors only when EDITING pages:

Warning: implode [function.implode]: Bad arguments in C:\Program Files\xampp\htdocs\wiki\includes\Parser.php on line 337

and

Warning: base64 decode expects parameter 1 to be string, array given in C:\Program Files\xampp\xampp\htdocs\wiki\crypt\RSA.php on line 390

Does anyone know a fix or what could be causing this? YES - read the paragraph before: It is a V1.6.7 problem.

Fatal error: Call to undefined method Crypt_RSA_KeyPair
When started for the first time, I have Fatal error:

Fatal error: Call to undefined method Crypt_RSA_KeyPair::toPEMString in E:\Program Files\xampp\htdocs\mediawiki-1.6.3\extensions\PageProtection\Encryption.php on line 21

My version info is

PageProtection-1.4

ApacheFriends XAMPP (basic package) version 1.5.1

+ Apache 2.2.0 + MySQL 5.0.18 + PHP 5.1.1 + PHP 4.4.1-pl1 + PEAR

--Miklev 16:42, 26 May 2006 (UTC)
 * I guess that Crypt RSA was not properly installed so your sctipt doesn know about that method. I've uploaded all-in-one archive that contains PageProtection extention, Crypt RSA and PEAR 200+ kb. It may help you. Write a message to me if you need it --Shtriter 17:07, 26 May 2006 (UTC)

--Karandras 12:00, 28 May 2006 (UTC +2)

I also installed that package and have nearly the same problem. I got this failure:

Warning: require_once(PEAR.php) [function.require-once]: failed to open stream: No such file or directory in C:\Programme\xampp\htdocs\knowledgebase\extensions\PageProte\ction\Encryption.php on line 5

Fatal error: require_once [function.require]: Failed opening required 'PEAR.php' (include_path='C:\Programme\xampp\htdocs\knowledgebase;C:\Programme\xampp\htdocs\knowledgebase/includes; C:\Programme\xampp\htdocs\knowledgebase/languages') in C:\Programme\xampp\htdocs\knowledgebase\extensions\PageProtection\Encryption.php on line 5

My version is:

ApacheFriends XAMPP (basic package) version

+ Apache 2.2.0 + MySQL 5.0.18 + PHP 5.1.1 + PHP 4.4.1 + PEAR + Crypt

And in my php.ini I have the line include_path = ".;C:\Programme\xampp\php\pear\"

And this is still the problem I suppose.

My Version of PEAR was preinstalled with the XAMPP installation. And the CRYPT package, too. The path to the packages is: C:\Programme\xampp\php\pear and to my wiki is C:\programme\xampp\htdocs\knowledgebase\

The only discription I found in the web is: PEAR will be preinstalled and run

What is my mistake? Could it only be the include_path?


 * Well, as in the previous case, it's wrong path in includes IMHO... First of all: Download PEAR, open archive and extract PEAR.php and /PEAR dir to your wiki dir (Where your Localsetting.php is). Then download Crypt_RSA-1.2.0b.tgz (afaik, Crypt_RSA-1.0.0 fails - see below). Extract RSA.php and /RSA dir into your_wiki/Crypt dir. Edit LocalSetting.php: add folowing lines

// disable caching $wgCachePages      = false; $wgCacheEpoch = 'date +%Y%m%d%H%M%S';

// Activate PageProtection extension. require_once("extensions/PageProtection/PageProtection.php");
 * That's all. Works fine for me!
 * PS. If all-in-one archive is needed - I've got one (200+ kb - in rar). But can't upload it to meta - rar is blacklisted...

-- Anonymous 12:00, 22 June 2006
 * I got this problem too. The problem was that I had the 1.0 version of Crypt_RSA, rather than the Beta 1.2 version, which is needed.

I'm having this EXACT same problem and these fixes don't seem to work. I am using XAMPP (same version) - can anyone post a clear tutorial on what needs to be edited/installed to get this running correctly? Thanks!

Fatal error in getText, PageProtection.php line 211
Received an error when accessing myserver/mediawiki/index.php?title=User:TestGroup1&action=edit

Fatal error: Call to undefined function getText in D:\IIS\devel\mediawiki\extensions\PageProtection.php on line 211

I'm not a wikiguru yet, please advise of a workaround. Bill D 03:01, 9 May 2006 (UTC)


 * I cannot reproduce the error on my local installation. What did you do, to produce the error? (Just edit a user-page?) What version of MediaWiki are you using? (http://myserver/mediawiki/index.php/Special:Version should give it to you). Maybe, in versions prior to 1.6, the WebRequest-Object ($wgRequest) does not have a method getText.
 * Also, I never could test the extension on IIS (I'll immediately add a list of tested environments to the article).
 * Btw, i'm also far away from a wikiguru (it's my first extension), so i really think, i'm using some internals wrong ;)
 * --Sirius gd 09:24, 9 May 2006 (UTC)
 * Btw, i'm also far away from a wikiguru (it's my first extension), so i really think, i'm using some internals wrong ;)
 * --Sirius gd 09:24, 9 May 2006 (UTC)
 * --Sirius gd 09:24, 9 May 2006 (UTC)


 * OK, i finally could reproduce the error (by random) and could fix it - sadly, after fixing it, i could not reproduce it with the original code. Could you try the new code and leave an answer here? --Sirius gd 16:49, 9 May 2006 (UTC)


 * New code installed, no more of that error! Thanks!
 * My version info is
 * MediaWiki: 1.6.5
 * PHP: 5.1.3 (cgi-fcgi)
 * MySQL: 4.1.14-nt
 * Bill D 02:40, 10 May 2006 (UTC)

Link on Page access restriction with MediaWiki page
Hi. Thanks for your link in See also section on Page access restriction with MediaWiki. I added some links on your page. Cheers, Jej 08:31, 9 May 2006 (UTC)

Error in Title.php
Getting notice of conversion in 4 places to Title.php. This one has me stumped.

Notice: Object of class User to string conversion in D:\IIS\devel\mediawiki\includes\Title.php on line 223

Notice: Object of class User to string conversion in D:\IIS\devel\mediawiki\includes\Title.php on line 226

Notice: Object of class User to string conversion in D:\IIS\devel\mediawiki\includes\Title.php on line 223

Notice: Object of class User to string conversion in D:\IIS\devel\mediawiki\includes\Title.php on line 226

Bill D 02:40, 10 May 2006 (UTC)

Nice mod, some issues
Thanks for a very nice extension, it looks like it will be very useful for us.

I'm a bit worried, however, that it is extremely easy to lock oneself out of being able to edit a section. If I put a section of my document in a &lt;protect&gt; section without the users or groups attributes containing a match for my account, the entire page becomes uneditable.

I don't really have much of a suggestion for improving this situation. I know that I can fix this for myself by making sure my account is in the 'sysop' group. Right at this moment, all of our accounts and groups are being synchronized from our Ganymede server, though, so I don't have any members in sysop.

Incidentally, I did have to make a few changes to get the extension to work properly with PHP 4.3.9, which is the supported version on our RHEL4 boxes. Nothing too difficult, mostly just some simplifications so that it doesn't try to use the -> operator, and changing a few parameters from pass by reference back to pass by value.http://meta.wikimedia.org/skins-1.5/common/images/button_sig.png

Jonabbey 01:27, 13 May 2006 (UTC)
 * I'm currently working on some things like storing protected text RSA-encrypted in the database so they are no longer searchable and telling the user to add himself to the list of allowed users for not accidently locking himself out. During the next week, I will probaly release a improved version.


 * If you have some suggestions for code-improvements, just tell me, i'l try to add them ;) --Sirius gd 10:10, 13 May 2006 (UTC)


 * Added the feature that the user currently editing a page is automatically added to the list of permitted users - hopes this helps you ;) Could you please check if for php 4.3.9 and send me the corrections? Thanks, --Sirius gd 20:12, 15 May 2006 (UTC)

Okay, great, thanks. One thing I'm looking at right now is to see if it's possible to separate view-protection from edit-protection. I'd like to be able to use a different variant of the &lt;protect&gt; element for protecting view, edit, or both.

Perhaps &lt;protect-view&gt;, &lt;protect-edit&gt;, and then &lt;protect&gt; for both?

I'm going to look at the code this morning to see how much work it looks like to get this done. --Jonabbey 14:34, 16 May 2006 (UTC)

Okay, I've got the PageProtection.php extension modified so that I can protect pages and sections as &lt;protect&gt; to protect a section from both editing and viewing, and &lt;protect-edit&gt; to protect a section against only editing.

See PageProtection/Sourcecode (Jonabbey) for my modified sources. I haven't looked at your RSA and self-editing mods yet, sorry. --Jonabbey 17:11, 16 May 2006 (UTC)


 * Look at 1.2, I added your readonly-feature with parameter show="text".--Sirius gd 04:49, 19 May 2006 (UTC)

Fatal Problem with Section Protection?
See Talk:PageProtection/Sourcecode (Jonabbey) for an extensive discussion of some of the shortcomings of this &lt;protect&gt; approach when it comes to sections. Basically, unless you apply &lt;protect&gt; down at each section, it looks possible for a user to inject a 'section=' to the URL for the page access, thereby bypassing the containing &lt;protect&gt;.

Jonabbey 23:32, 17 May 2006 (UTC)


 * I'Ve allready been aware of this problem. In the current version it is fixed by only letting users edit section that can edit all sections in this article. I tried some ways out but there were always problems. hopefully I will find a way to get this better ;) --Sirius gd 04:49, 19 May 2006 (UTC)

Holes
Nice mod, thanks a lot for working on this! There are currently ways to get around the protection though


 * When viewing the history of a page and comparing versions of the page, the protected areas are displayed normally.
 * Similarly, when viewing "diff" in the Recentchanges page the protected areas are displayed
 * The RSS feed for Recentchanges and Newpages contains the protected areas

Any chance you could try to block these views as well? IMO it'd be sufficient to not show any changes at all for pages containing protected sections. I suck at PHP, otherwise I'd give it a shot myself.


 * OK, all your holes should be fixed now, as all content is stored RSA-encrpyted. Sorry for the currently bad documentation of installing and creating RSA-keys, will be better the next days ;) --Sirius gd 20:12, 15 May 2006 (UTC)

Version 1.2
The show="none" seems not working. How to display nothing ?
 * Fixed in 1.3 --Sirius gd 05:40, 24 May 2006 (UTC)

Error with mediawiki 1.6.5 and linux redhat ES4
When i activate Permissions 1.2 i have this error: [client 191.254.42.78] PHP Notice: Use of undefined constant MSG_NO_ACCESS - assumed 'MSG_NO_ACCESS' in /export/home/frtdevrep/www/mediawiki/extensions/PageProtection/PageProtection.php on line 6, referer: http://frontools/wiki/index.php?title=MediaWiki:PageProtection [client 191.254.42.78] PHP Parse error: parse error, unexpected T_OBJECT_OPERATOR in /export/home/frtdevrep/www/mediawiki/extensions/PageProtection/AccessList.php on line 78, referer: http://frontools/wiki/index.php?title=MediaWiki:PageProtection


 * One question, where were theses errors printed? I could not find them in any log-file? The first error is definetively fixed in 1.3, the second one hopefully too ;) --Sirius gd 05:42, 24 May 2006 (UTC)

My version is: and mediakiki fail to renderer all pages. Thx Christophe
 * 1)  MediaWiki: 1.6.5
 * 2) PHP: 4.3.9 (apache2handler)
 * 3) MySQL: 5.0.20a-standard


 * I currently don't have a PHP 4 test environment but hope to get one up to the weekend. Could you try 1.3?


 * OK, i installed PHP4 and fixed some small bugs for that version - hope it works now ;) --Sirius gd 14:00, 24 May 2006 (UTC)

No errors, but doesn't work either
I don't get any errors, but the tag just doesn't work (No matter what the username is, it still shows the "protected" text. Is there a way to debug any of this? I ran the pear-Crypt_RSA test files and they work fine, I just don't know what to do at this point.

My version:


 * 1) MediaWiki: 1.6.3
 * 2) PHP#  5.1.2 (apache2handler)
 * 3) MySQL: 5.1.7-beta-log
 * 4)  Extensions:

* Parser hooks: o Inputbox by Erik Moeller o ProtectPage (version 0.7) by Fabian Schmitt (http://meta.wikimedia.org/wiki/User:Sirius_gd) * Extension functions: o registerInputboxExtension, wfSyntaxExtension, wfGraphVizExtension and wfPageProtection * Parser extension tags: o, , , , , , , , , , , , , , , , ,, , , , , , , , , , , , , , , ,, , , , , , , , , , , , , , ,, , , , , , , , , , , , , , , and 


 * 1) Hooks:

* AlternateEdit: protectedEdit

I thought I had the same problem, but it turns out that I was using my account which belongs to 'sysop' (which is always allowed to view protected text). If I just log out and view as anonymous, the protected text works.

Uncrypt in diff
The diff function is instead unusable ...
 * It would be great to display in diff the text uncrypted if the profil of the reader allows it.

Romain 05/25/2005

Troubles and wishes
The extension is cool. But I've found some small incompatibilities and wishes for it.

Crypt-RSA
First of all, I don't know why exactly, but Crypt-RSA outputs too much notes like: Notice: Only variable references should be returned by reference in ...wiki\Crypt\RSA\MathLoader.php on line 127

Notice: Undefined variable: in in ...wiki\Crypt\RSA\KeyPair.php on line 235


 * The cause of the error is described in http://pear.php.net/bugs/bug.php?id=7254. I tried the fix mentioned on the page, but then I got a fatal error. I had to get it working and didn't have the time to really fix it, but with a little snooping around I found that Crypt_RSA was trying GMP and BigInt first before BCMath (since they're faster). If your server doesn't have them, the ugly notice will appear. Since I knew that my server didn't have any of the two, I just modified line 81 of RSA\MathLoader.php from:

static $math_wrappers = array('GMP', 'BigInt', 'BCMath',);


 * To:

static $math_wrappers = array('BCMath');


 * Hope that helps somebody! --Rico Nagtalon 22 September 2006

And I we'll try to use Crypt_RSA-1.0.0.tgz PageProtection wouldn't work too. The first Crypt_RSA version doesn't have toPEMString function.

Fatal error: Call to undefined function: topemstring ...wiki\extensions\PageProtection\Encryption.php on line 21

PHP4
The second trouble is the message that PageProtection works in PHP4. In my case it returns: Fatal error: Call to undefined function: file_put_contents in ...wiki\extensions\PageProtection\Encryption.php on line 22 Afaik, PHP4 doesn't have file_put_contents function. And PEM-file wouldn't be created until we'll add the function in Encryption.php (found in Web):

// Check to see if function exists if (!function_exists('file_put_contents')) {

// Define constants used by function, if not defined if (!defined('FILE_USE_INCLUDE_PATH')) define('FILE_USE_INCLUDE_PATH', 1); if (!defined('FILE_APPEND'))          define('FILE_APPEND', 8); // Define function and arguments function file_put_contents($file, &$data, $flags=0) {        // Varify arguments are correct types if (!is_string($file)) return(false); if (!is_string($data) && !is_array($data)) return(false); if (!is_int($flags)) return(false); // Set the include path and mode for fopen $include = false; $mode   = 'wb'; // If data in array type.. if (is_array($data)) { // Make sure it's not multi-dimensional reset($data); while (list(, $value) = each($data)) { if (is_array($value)) return(false); }            unset($value); reset($data); // Join the contents $data = implode('', $data); }        // Check for flags.. // If include path flag givin, set include path if ($flags&FILE_USE_INCLUDE_PATH) $include = true; // If append flag givin, set append mode if ($flags&FILE_APPEND) $mode = 'ab'; // Open the file with givin options if (!$handle = @fopen($file, $mode, $include)) return(false); // Write data to file if (($bytes = fwrite($handle, $data)) === false) return(false); // Close file fclose($handle); // Return number of bytes written return($bytes); } }

I used: PHP_Compat

PHP_Compat provides missing functionality for older versions of PHP. http://pear.php.net/package/PHP_Compat/



Unprotected sections can't be edited too
What is the need in closing tag if it doesn't prevent the protection of the whole page? It would be great to make the wikitext not encapsulated in tag editable or at least to use smth like ?

Btw, when I tried to save and got  AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

Summary
So I think that it is necessary to extend this HowTo. In particular, specify the versions of used modules and default parameters. IMHO, it would be smart to store all code in the extensions\PageProtection folder and of course don't make the user to download and setup 3 different libs.

PS. I've tested PageProtection in Windows XP with Denwer-2 2005-10-07 and enhanced AltDenwer 1.4.
 * MediaWiki 1.6.1 and MediaWiki 1.6.5
 * Apache 1.3.31
 * PHP 4.4.0
 * MySQL 4.1.8

getWrapperName error
i have this error: Fatal error: Call to a member function getWrapperName on a non-object in /usr/share/pear/Crypt/RSA/KeyPair.php on line 698 Any idea ? Thx PS: i have generetae my private/public key like this: openssl genrsa -out private.pem openssl req -new -x509 -key private.pem -out public.pem -days 365000

My env:
 * 1)  MediaWiki: 1.6.5
 * 2) PHP: 5.1.4 (apache2handler)
 * 3) MySQL: 5.0.20a-standard
 * 4) Crypt_RSA: 1.2.0b

I have the same problem. As far as I've been able to figure out, seems to be that Crypt needs php to be compiled with one of GMP, BigInt, or BCMath. The easy fix would be to configure php with the --enable-bcmath option.

problem with editing and the group parameter
The group parameter is not used if you want edit a page. Only the delivered users and the sysop group members allowed to edit the page.

After a look into the code i removed the line $this->AddGroup("sysop") inside the AccessList function in the AccessList.php file. Now the edit behaviour works fine but the sysopt is not added automatic to the group parameter during a new protect area is saved.

/** * Constructor. Creates default user-list and ensures sysop * is in allowed groups. * @param users Array or comma-separated users-list. * @param groups Array or comma-separated groups-list. */ function AccessList($users = null, $groups = null) {    $this->AddUsers($this->getArray($users)); $this->AddGroups($this->getArray($groups)); //   $this->AddGroup("sysop"); }

After add the row $access->AddGroup("sysop") inside the function getEncrypted within the ProtectionParser.php file the sysop group is added during each save.

/** * Retrieves text of this object with all protect-tags beeing * encrypted before. * @return Text with encrypted tags. */ function getEncrypted($userName) {    require_once("ProtectTag.php"); $text = $this->mParsedText; foreach ($this->mContent as $rand => $cnt) { $access = new AccessList(  $this->mParams[$rand]["users"],                                        $this->mParams[$rand]["groups"]); $access->AddUser($userName); $access->AddGroup("sysop"); $tag = new ProtectTag; $tag->setAccessList($access); $tag->setShow($this->mParams[$rand]["show"]); $tag->setErrorPage($this->mParams[$rand]["errorpage"]); $text = str_replace($rand,            $tag->getStart."\n"                 .$this->mEnc->encrypt($cnt)."\n"                 .$tag->getEnd,             $text); }    return $text; }

Public and Private key generation
I use ssh-keygen to generate the keys. Be sure to place them in the wiki directory before you activate this extension as the extension needs it to create the correct private.pem.

I'm getting the following error when viewing a protected page. Notice: Undefined variable: in in C:\Wiki\mediawiki-1.6.7\Crypt\RSA\KeyPair.php on line 235 And I get the following errors when viewion or editing a protected page: Notice: Undefined variable: in in C:\Wiki\mediawiki-1.6.7\Crypt\RSA\KeyPair.php on line 235 Warning: implode [function.implode]: Bad arguments. in C:\Wiki\mediawiki-1.6.7\includes\Parser.php on line 337

The error on line 235 is a typo, I solved the error by making the following change:
 * Was:$len |= ord($in[$pos++]);
 * To:$len |= ord($n[$pos++]);

I presume it's because I'm missing the public key. I'm running on a Windows 2003, with IIS. I see where the private key was gnerated and placed into "private.pem" but I don't see the public key. How do I manually create the public key?

Protection or substitution of private.pem
After some issues (gmp support, downgrade to 1.6.6 Parser.php), I have successfully installed PageProtection and so far it seems to protect the information quite well. Just one thing: the private.pem rests in my mediawiki directory and must be readable at least to the apache user. Which in turn means everybody could download it, just by entering http://mywiki/mediawiki/private.pem in a browser.

What is the suggested method of protecting private.pem?


 * I'm not very keen at cryptography, but I think that we can try to use such personal info as login or password (even hashed), that is stored i DB. IMHO, that approach will help us to avoid storing the key in file that is important if the wiki is distributed on the local webserver.


 * Apache users: you can protect the private key with a Deny directive for the file in httpd.conf or .htaccess in the same directory as private.pem. Personally, I wrote this rule in an .htaccess</tt> file:

<Files "private.pem"> Order Deny,Allow Deny from All </Files>

Subpages protection
I came to the conclusion that introducing the feature of the policy descending is very important. Even more. We shall have the overriding ability for the descendant pages too. So, my idea is to specify the page name in the attribute and If a sub page is edited the policy of the descendant that has the specifid name is used. If we override it - the inner subpage's name is used in the policy insted of the parent.

Allow/Restrict transcluding
I also think that managing the process of trunsclusion is also important for the protected pages. So I consider that new attribute is needed.

PS. The list is open. Feel free to comment and and new items! --Shtriter 05:32, 10 July 2006 (UTC)

Deletion of pem files renders protected pages as Hashes!
Unfortunately, both the Public and Private pem files that were created by the mod were deleted. I thought, "not to worry, logout and log back in and the said files will be created again" which they were BUT the pages that were protected and the sections of Text that were also protected now display a HASH inbetween the Tags! "Ok" I thought, then disable the Mod in my LocalSettings file and all will be revealed but to my Horror, they still display the HASH.!

Could someone please tell me the best way to recover my work which seems to be lost through the HASHs? Or explain the best way to recover this Mods actions after a .pem deletion?

Many Thanks. --skdb 23:26, 15 July 2006 (UTC)


 * There really isn't a solution to this problem. The tradeoff to security is the risk of data loss.  So far as I can tell the pem used by default is randomly generated, which has the advantage of being quite secure and the downside of being totally irrecoverable if lost.  Since the computing power really doesn't exist at the moment to attack keys of the size used, I'd say your data is, well, gone.  Well, not gone actually, but it will be several centuries before Moore's law catches up and makes RSA forcing possible for the masses.  -Verlocs

Doesn't work in 1.7.1
Hi,

Page protection doesn't seems to work in the new 1.7.1 release. Any idea on how to fix it?

Thanks!

I've gotten it to work with 1.7.1, but it seems really slow. It takes about 6-7 seconds to view a page that has the tag in it. To get it to work I installed the 1.2beta of Crypt_RSA and also had to recompile my php with the '--enable-bcmath' option.

Does anyone know of a way to speed it up?

Thanks!


 * What manner of computer are you using as a server? Because naturally there is going to be some overhead for dealing with encryption and decryption (actually, a fairly great deal of overhead).  More specific information about your environment would be helpful. -Chris V.


 * Yer i have this same problem i just tried the 1.7.1 experimental patch.. seems to slow down getting to the edit page and also saving the edit page. Definately not a computer issue, was working ok before.. now really slow. I'm not sure how you profile a php page besides going thru and putting trace statements thru it..


 * The problem is half bcmath and half systemic to what you're trying to do. BCmath is one of the worst math libraries that exists for doing the sort of tasks needed for encryption.  If you dig through the CryptRSA and php docs you'll eventually find that they recommend gmp or big_int over bcmath.  Using a library other then bcmath will slice a healthly amount off the encryption times.  However, there is also the fact that you are performing an encryption task.  Understand, encryption and decryption are the REASONS supercomputers were created in the first place, and RSA is intended to make encryption hard to break for machines that were first created to break encryptions.  The consequence of this is that encryption time grows somwhere between linearly and expoentially as the length of the encrypted block increases.  Two words will encrypt much, much faster then two pages of words.  This must be accepted as a consequence and tradeoff of security.  That said, it's worth it.  -Verlocs

LDAP Group Support
The code below is a modification of the AccessList.php hasAccess function, to allow the usage of ldap groups. I'd recommend using Talk:PageProtection as well if you plan to use this in your environment.

This code is designed for wiki sites using the LDAP Authentication extension, where user's ldap login uids would be the same as their wiki usernames. Using that assumption, the code searches ldap using the wiki user's identity, and extracts their group membership data. Then, it searches LDAP again to get each group's cn, which is then compared to the list of allowed groups.

This code is not immediately functional; it will require modification to work with any given ldap environment since they're all different. But for internal business wikis it allows contributors to restrict access using groups they might already be familiar with using.

Naturally, your php deployment must have ldap support for this to work. function hasAccess(&$user) { require_once("includes/User.php"); foreach($this->mGroups as $group) { if(in_array($group, $user->mGroups)){ return true; }       }        if(in_array("sysop", $user->mGroups)){ return true; }       if (in_array($user->getName, $this->mUsers)) { return true; }

/** Begin Code for LDAP Groups * 		**/	$ldapconn = ldap_connect("!!LDAP Server!!"); if ($ldapconn) {		$ldapUserGroupDN = "!!Deepest DN that includes all users and groups!!"; // Set Options ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3); ldap_set_option($ds, LDAP_OPT_REFERRALS, 0);

// Bind ldap_bind($ldapconn, "!!BIND USERNAME!!", "!!BIND PASSWORD!!");

// Get User Information $userFilter = array("memberof"); $uidString = "uid=".$user->getName; $userMemberOfResults = ldap_search($ldapconn, $ldapUserGroupDN, $uidString,$userFilter); $userMemberOfEntries = ldap_get_entries($ldapconn, $userMemberOfResults);

// Get and Test Group CNs for ($i=0; $i<$userMemberOfEntries[0]["memberof"]["count"]; $i++) {			$groupFilter = array("cn"); $groupResults = ldap_search($ldapconn, $userMemberOfEntries[0]["memberof"][$i],"cn=*",$groupFilter); $groupEntries = ldap_get_entries($ldapconn, $groupResults); if (in_array($groupEntries[0]["cn"][0], $this->mGroups)) { ldap_close($ldapconn); return true; }

}		ldap_close($ldapconn); }

// End LDAP Group Code

return false; }

-Chris V., 7.27.2006

The above didn't work for me so i edited it a bit, and reduced number of ldap calls:

function hasAccess(&$user) { require_once("includes/User.php");

foreach($this->mGroups as $group) { if(in_array($group, $user->mGroups)){ return true; }       }        if(in_array("sysop", $user->mGroups)){ return true; }

if (in_array($user->getName, $this->mUsers)) { return true; }

/** Begin Code for LDAP Groups *       **/        $ldapconn = ldap_connect("myldapserver.mydomain.com"); // put in your ldap server if ($ldapconn) {               $ldapUserGroupDN = "ou=Groups,dc=mydomain,dc=com"; //this should be the DN to your groups

// Set Options ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3); ldap_set_option($ds, LDAP_OPT_REFERRALS, 0);

// Bind ldap_bind($ldapconn, "", ""); // you can bind anonymously or enter username/password for authentication

// Get User Information $userFilter = array("cn"); $uidString = "memberUid=".strtolower($user->getName); // note 'memberUid' is how my users are stored in a group $userMemberOfResults = ldap_search($ldapconn, $ldapUserGroupDN, $uidString,$userFilter); $userMemberOfEntries = ldap_get_entries($ldapconn, $userMemberOfResults); ldap_close($ldapconn);

// theres probably a better way to do this next line, rather than parsing and splitting group list // but this should be quick anyway $groups = preg_split("/,/", $this->mAccess->getGroupList); for ($i=0; $i<count($userMemberOfEntries); $i++) {                   if (in_array($userMemberOfEntries[$i]["cn"][0], $groups)) {                       return true; }               }        }        // End LDAP Group Code return false; }

I too exprienced difficulty with the above LDAP. After digging through my AD server, I discovered the key that represents uid in Acative Directory. This is samaccountname. If your looking for an AD browser, there is one built in to W2K and W2K03, look here  This is how I plowed my way through this horrible implementation of Ldap we all know and Hate Active Directory.

function hasAccess(&$user) { require_once("includes/User.php"); foreach($this->mGroups as $group) { if(in_array($group, $user->mGroups)){ return true; }   }    if(in_array("sysop", $user->mGroups)){ return true; }   if (in_array($user->getName, $this->mUsers)) { return true; }   /** Begin Code for LDAP Groups *    **/   $ldapconn = ldap_connect("ldap_server_connection_path"); if ($ldapconn) {       $ldapUserGroupDN = "dc=whatever,dc=something,dc=com";

// Set Options ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3); ldap_set_option($ds, LDAP_OPT_REFERRALS, 0); // Bind ldap_bind($ldapconn, "aduser", "aduserpass"); //needed to to bind // Get User Information $userFilter = array("memberof"); $uidString = "samaccountname=".$user->getName; $userMemberOfResults = ldap_search($ldapconn, $ldapUserGroupDN, $uidString,$userFilter); $userMemberOfEntries = ldap_get_entries($ldapconn, $userMemberOfResults);

// Get and Test Group CNs for ($i=0; $i<$userMemberOfEntries[0]["memberof"]["count"]; $i++) {           $groupFilter = array("cn"); $groupResults = ldap_search($ldapconn, $userMemberOfEntries[0]["memberof"][$i],"cn=*",$groupFilter); $groupEntries = ldap_get_entries($ldapconn, $groupResults);

if (in_array($groupEntries[0]["cn"][0], $this->mGroups)) { ldap_close($ldapconn); return true; }         }        ldap_close($ldapconn); }    // End LDAP Group Code return false; }


 * I never said my original implementation was very good... -Verlocs.

Patch for 1.7.1
Here is a patch for 1.7.1 (based on patch for 1.6.8) Strongly experimental.

Priyatosha

Fatal Error
Dustin, 09/15/2006

I've run into some problems with this. When a page is viewed by an approved user, all is well. When an unapproved user attempts to view it, the following PHP error is thrown: Fatal error: Call to undefined method Parser::parseTag in /var/www/extensions/PageProtection/ErrorHandler.php on line 73 The call is found in ErrorHandler.php: function formatMessage($msg, $parseWiki = true) { global $wgOut; $msg = str_replace(VAR_USERS, $this->mAccess->getUserList, $msg); $msg = str_replace(VAR_GROUPS, $this->mAccess->getGroupList, $msg); if ($parseWiki) { return ($this->mParser1->parseTag($msg)); <-- 73 } else { return $msg; } } This occurs during the processing of ErrorHandler.php at: function getErrorMessage($parseWiki = true) { $msg = wfMsg("ProtectedSite"); return $this->formatMessage($msg, $parseWiki); <-- } which is called here in ErrorHandler.php: function showError($text = "") { if ($this->mShow == "crypt") { return $text; } else if ($this->mShow == "page" && $this->mPage != "") { return $this->getErrorPage; } else if ($this->mShow == "none") { return ""; }  return $this->getErrorMessage(true);  <-- } which is called here in PageProtection.php at: function protectPage( $text, $params, &$parser) { $parser->disableCache; global $wgUser; global $wgOut; $protect = new ProtectPage($parser); $protect->initShow($params["users"], $params["groups"], $params["show"]); if ($protect->hasAccess($wgUser)) { global $wgRequest; $text = $protect->mEnc->decrypt($text); $text = $protect->parseTag($text); return ($text); }  $show = $params["show"]; $page = null; if (isset($params["errorpage"])) { $page = $params["errorpage"]; }  $err = new ErrorHandler($protect->mAccess, $parser, $show, $page); return $err->showError($text); <-- } My only assumption is that something is wrong with the instantiation of the ErrorHandler object ($err->mParser1 doesn't find parseTag located in ProtectPage.php). Incorrect parameters? In this case, these are the contents of those variables:
 * $protect->mAccess
 * an AccessList Object containing information about valid users and groups


 * $parser
 * a very large Parser Object


 * $show
 * "warning"


 * $page
 * null


 * $err
 * a very large ErrorHandler Object, due to it having the same data as $parser stored in $err->mParser1


 * $text
 * "qspB6Luq7G2NspkDYPxvE2IyAL/2e8W8gdttPZPbg3k=", the encrypted text

all of which seem to have the correct data types and information in them. parseTag is found in ProtectPage.php: function parseTag ($text) { $text = $this->mParser1->parse( $text, $this->mParser1->mTitle, $this->mParser1->mOptions, false, false ); $text = $text->getText; $text = preg_replace ('~^ \s*~', '', $text ); $text = preg_replace ('~\s* \s*~', '', $text ); $text = preg_replace ('~\n$~', '', $text ); return ($text); } which is defined in the class ProtectPage. Does the parseTag function need to be defined for Parser objects (the datatype of $err->mParser1), or does line 73 need to return something else? Is there anything else that stands out as incorrect to anyone? What am I missing?

Fix
The function can actually be fixed by fixing the parseTag function. The second parameter of the ErrorHandler constructor should not be $parser, but in fact should be a reference to the ProtectPage object (i.e. $protect). Here's the changed code fixed off of my test server.

function protectPage( $text, $params, &$parser) { $parser->disableCache;

global $wgUser; global $wgOut; $protect = new ProtectPage($parser); $protect->initShow($params["users"], $params["groups"], $params["show"]);

if ($protect->hasAccess($wgUser)) { global $wgRequest; $text = $protect->mEnc->decrypt($text); $text = $protect->parseTag($text); return ($text); }   $show = $params["show"]; $page = null; if (isset($params["errorpage"])) { $page = $params["errorpage"]; }   $err = new ErrorHandler($protect->mAccess,     				$protect,                                $show,                                $page); return $err->showError($text); }

Problem: Entire page becomes un-editable, when trying to only lock a small section
Someone else mentioned this same problem above, and I did contact Sirius directly (http://meta.wikimedia.org/wiki/User_talk:Sirius_gd) with details on this. If we find the answer, please post here. As the manual states "Protect pages / sections / textblocks" We just want to protect a small area at the top of a page (to be edited by admin/sysop only), but let the rest of the page be editable by other users.


 * As implemented, the page protection system works like this: IF a protected section would appear in the edit window if they had access, then they can't edit if they don't have access. The top Edit button will ALWAYS be broken for people without access, because they can't load the text to be edited without hitting the protected region.  The only way they can edit content on a page with protection is if they're editing a section of the page that doesn't have protected content they can't access.  Personally, I think this is a good practice, not a bug.  -Verlocs

Connection refused when attempting to download
Unless I'm being a total idiot, the website that this extension is hosted on isn't available. I tried it yesterday and it didn't work so figured that some cosmic rays might be at work, so left it for a while to see if it would work today.

It doesn't. When attempting to wget it, I get this:

wget http://sirius.o00.de/files/PageProtection-1.4.tar.gz 2>&1 --19:46:40-- http://sirius.o00.de/files/PageProtection-1.4.tar.gz           => `PageProtection-1.4.tar.gz' Resolving sirius.o00.de... done. Connecting to sirius.o00.de[213.239.206.107]:80... failed: Connection refused.

I can't locate any other place this is hosted when googling for it. Anyone got any clues?

section-editing-problem
My system:
 * MediaWiki: 1.6.7 (patched to enable page access restriction)
 * PHP: 4.3.9 (apache2handler)
 * MySQL: 4.1.20
 * PageProtection 1.4

Example: <protect show="warning" users="username" groups="sysop"> == 1.Teil == == 2.Teil ==

When I try to edit 1.Teil and add some text (blablabla), then the wiki makes the following:

<protect show="warning" users="username" groups="sysop"> == 1.Teil == == 2.Teil == == 1.Teil == (blablabla)

and not: <protect show="warning" users="username" groups="sysop"> == 1.Teil == (blablabla) == 2.Teil ==

This problem occours only when editing the section directly and not when editing the whole page!

What can be wrong? Thank you for helping!

Crypt/RSA/KeyPair.php: Call to a member function on a non-object
I have a problem to get the extension running.

(PageProtection 1.4, Crypt_RSA 1.2.0b, MediaWiki 1.6.6, PHP 4.4.0, Apache 2.0.49)

When trying to edit a page, the following error occurs:

"Fatal error: Call to a member function on a non-object in /usr/share/php/Crypt/RSA/KeyPair.php on line 698"

The line in question is in the method fromPEMString of the class Crypt_RSA_KeyPair:

"$wrapper_name = $this->_math_obj->getWrapperName;"

I already removed Crypt_RSA 1.0 to be able to install v1.2.0b, and I installed PHP_Compat.

Any ideas? Thanks! --TobiasHerp 16:15, 17 October 2006 (UTC)

Strange error (with 1.7 and above)
I'm using the somewhat working version for 1.7+ and I noticed, anytime  or something is in a page, it converts it to the syntax. Has anyone else noticed this? I know it's not an official release, but does anyone know when a new version of this extension will come out? It's absolutely amazing!

Approved user cannot read/edit page
Hi, i got MediaWiki 1.8.2 with PageProtection-1.4-2 AND MediaWiki 1.6.3 with PageProtection-1.4 both installs with PEAR-1.4.11 and Crypt_RSA-1.2.0b

On both unapproved users get the warning msg as they should, but approved users get the following error on both installations:

Fatal error: Call to undefined method PEAR_Error::getPrivateKey in /www/laboratorios/lapo/wiki/extensions/PageProtection/Encryption.php on line 46

What could b wrong? any ideas? =/