Extension talk:PageProtectionPlus

'''Purpose of this page is to gain questions and answers about the architecture and features. To know more about installation and usage related topics please go to Extension talk:PageProtectionPlus/Installation Guide'''

Listing of all encrypted articles
Q: Is there a possibility to list all encrypted articles?

A: Not yet. I'm wondering whether it should be realized in some other way, like by categorizing them when there is a need.

Per user/group read only pages
Q: Is it possible to specify the users/groups who can edit a page and the users/groups who can read it? If so, how can it b done?

A: This extenstion provides access restrictions that are concerned about content protection in general (read/write/edit) using cryptography. To get want you want (allow view and disallow edit for example) you have to use different extension (or combine it with it).

Compatibility
Q: Does it work with MediaWiki 1.9.3 ?

A: Looks like it does, just upgraded about an hour or so ago and things are ok so far.

Q: What about MediaWiki 1.10.0?

A: Looks like it works.

Read access works, edit doesn't
Q: I have the following section on my wiki page:  Database-Settings asdf secret and this line in LocalSettings.php: $wgGroupPermissions['projectadmin']['edit'] = true; and a user in the groups projectadmin and Bureaucrats via Special:Userrights.

The user can see the protected part of the page, other users not in the right group get the error page.

But: my user in projectadmin group can not edit the page with the protected section in it. Error is 

PPP is 2.1b (Special Pages) and 2.0b (Parser Hooks), reported like this by Special:Version; MediaWiki is 1.9.1

What can I do? --149.226.255.200 14:03, 9 February 2007 (UTC)

A: Unfortunately this is broken by design, since there is no easy way in MediaWiki to edit part of page in a way that page is sliced and then joined after edit (saving protected sections intact). It can be worked-around in PPP code by allowing encrypted version to be shown to unprivileged users but we're risking in lack of integrity – user can spoof an encrypted part or make it unreadable.

The workaround which seems to be quite simple is to create a plain page and important encrypted parts as different pages. Then use some other MediaWiki extension to incorporate contents of encrypted parts into parent page in-real-time (not checked).

compare versions does not work
MediaWiki 1.9.2 with diff3

Compare versions does not work, diff3 compares the encrypted pages, but it should compare decrypted pages!

/edit: makes no difference if diff3 is used or internal diff

--14:29, 13 February 2007 (UTC)

Warnings in 2.2b
Since I upgraded from 2.1b to 2.2b I get lots of warnings like this: PHP Warning: array_key_exists [function.array-key-exists]: The first argument should be either a string or an integer in ...wiki/extensions/PPP/KeyHeap.php on line 255 Is that critical?

MW 1.11.0

-- Florian.Lindner _AT_ bshg.com

Whole wiki encryption
Hi, I was wondering if it's possible to encrypt the whole wiki by default. I want to use this against the serverhost, because I was looking to write some personal data, and would not like to let "anyone in the world" read it... (No I'm not a fanatic terrorist :P). Or should I try to find some other software to do this kind of thing?

-- Paul

Page cannot be displayed
Hello!

I've the Problem, that if a user tries to edit an articel which is partly portected,then he gets a "this page can't be displayed" page... It's possible to get there something like "Editing this page is restricted"?

Further strange thing if i protact a part of this page and then I edit another Page of this Page, I'll get the same "this page can't be displayed" Page.

Any Advice or Workaround?

greets franz

Problems with this extension
Though I genuinely like the idea of this extension, there are various problems:
 * Note: writing as of 2.3b, with MediaWiki 1.12.0
 * Lots of bugs. From the mundane to the important
 * in protectedEdit, the second call to ErrorHandler should pass in $protect, not $wgParser
 * all the internationalization messages are incorrect. All keys need to be in lower-case (actually, just the first letter, which is an oddity of MW).
 * The above were found in the first trial uses, so what other bugs lurk?
 * One key to rule them all?
 * it would make much more sense if keys were generated on a per-user and per-group basis and each password-protected by the user's own login credentials. This way, if there were a web-server or wiki exploit, the data in these pages would still be secure.
 * No caching?
 * Surely it's possible to invalidate the cache as needed, when needed.

I realize this is free; I hope the authors don't take my feedback the wrong way. Rather, these are things that should be done to enhance the public usability of this extension. --Otheus 08:49, 11 July 2008 (UTC)