Extension talk:PageProtection/Development

This page is for talking about the development of the PageProtection-extension.

If anyone is interested in helping coding, i would appreciate any help. A public SVN-repository then of course would be great ;)

Future Features

Compatibility issues

• Working with PHP 4?
  • Yes, but 1 function (file_put_contents() - described on Talk:PageProtection) is needed for PEM file creation.

• Another way would be using PHP_Compat that also provides file_get_contents for PHP < 4.3 and maybe automatically solves other problems for older versions. If i include PEAR_Crypt, i also could use this pear-package --Sirius gd 04:34, 30 May 2006 (UTC)

• Checking compatibility with MediaWiki Versions (I currently develop on SVN)
  • I see no other compatibility problems except 1.6.x requirement. As I've said, adding file_put_contents() function made PageProtection work on almost the minimal requirements for MW 1.6.x:
    • MediaWiki: 1.6.1 (also MW 1.6.5)
    • PHP: 4.3.10 (apache 1.3.31)
    • MySQL: 4.1.8-max

Encryption

The current version is dependand on PEAR/Crypt - that is not the best solution. As the encryption-methods are in a separate class, it would be easy to add other algorithms. The best would be an easy and small implementation to add to PageProtection so there are no dependencies in the installation-package and have the ability to use PEAR/Crypt or other encryptions. Any suggestions for an algorithm to use as default are welcome ;)

Why not to copy all required functions into encryption module? (Afaik they are under PHP3 license)

Sounds a good alternative ;) I have to check PHP-License 3

As far as i understand the PHP-License 3, i directly can include the pear-packges as long as

1. I include the license file (don't know if this is needed, but shuold be better)
2. Add

   "This product includes PHP software, freely available from <http://www.php.net/software/>".

   to the readme.
3. Have the copyright-notice of PHP-License - this is automatically done, when including the complete pear-packages.

And if we'll look on it from another point of view, we'll see that future encryption developments won't leed to PageProtection code changes - just update necessary library!

RSA? this is overkill in my opinion, you're sacrificing so much speed that it's just crazy, the better thing to do would be use mcrypt and then mcrypt_encrypt(); and the decrypt equiv along with 3DES and a key of choosing to do the job... that would be perfectly acceptable, and anyone with issues of high sensitivity should probably be submitting it to the server pre-encrypted...

Editing of sections

Section not containing any protect-tags should be editable by everyone. I think this feature would be very useful.

Well, I've ment not only section but the whole text that is not in <protect>..</protect> tags. So that if article contains only one section not allowded user still can edit unprotected text and for the protect he see's only blank or hashed <protect/> tag. These users must not have ability to change or delete protected area though...

I don't think that would be easy to implement. Protected section had to be stripped of the text before the edit-page is displayed. On saving, the protected section had to be reimplemented. But what, if the user completely redesigns the page (clears all other contents, ...), theres now way to find out, where to readd the protected sections.

No such a big problem. If user don't want the page to be completely overwritten - he can protect it. Anyway sections can be used to determine where to paste <protect> tags (in section begining or ending). If no section is found - protect tags are pasted in the begining (or ending - customisable) of the article.--Shtriter 03:53, 30 May 2006 (UTC)

The other smart way - is to use blank or hashed <protect/> tag mentioned above. I meant that if user deletes or changes position (if possible) of the tag, alert message is shown on page submition. Some js tips can be used too.--Shtriter 03:53, 30 May 2006 (UTC)

Sounds interesting. I think, the biggest flexibility would be given if everything is possible ;) So, what if the protect-tag contained another one parameter that sets the right for editing the sorrounding text. The user having access to the tag can set, if others can move the position of the tag (without changing or deleting it), delete it or do nothing. Something like

<protect ... edit-rights="none|move|remove"

. When a user deletes the tag, he gets an error with the tag beeing shown outside the edit-box.

What ways of displaying the protected-tags are there?

1. __PROTECT_N (N=1..X)
2. Hash-Value (maybe like Parser::extractTagsAndParams returns)
3. The crypted tag

My favourite is the first way, as it is IMHO the least confusing one. --Sirius gd 04:54, 30 May 2006 (UTC)

I agree with you. Maybe it can be customizable too. The most interesting point: what will be shown if extention failed? Afaik, crypt text now.

As for the proposed edit-rights syntax. It's great too. Imho default value must be move. Because none can be specified like this <protect ... />

--Shtriter 13:45, 30 May 2006 (UTC)

In general, from my point of view, it's time to formalize PageProtecion syntax. I meen it would be good to describe implemented and desirable attributes, default values and of course discuss syntax-related questions. --Shtriter 16:03, 30 May 2006 (UTC)

Hiding allowded users and groups from others

Ability to hide the list of allowded user and groups from those who have no permission to edit protected area is very desirable.

Do you want to display an error-message not containing the usernames and groups? Then just modify the message ProtectedSite from the special-page Allmessages or create an error-page containing the error-message (e.g. "PageNoAccess") and set show="page", errorpage="PageNoAccess". Solves that your request or did you want something else?

Afaik when restricted users edit protected pages they can see the list of allowed users/groups in <protect> tag atrriutes. Not good for me. And as for the message, I know I can change or don't display it. But imho it would be smart to have and atribute that will determine what type of message to display for the tag: with user list or without it.--Shtriter 03:53, 30 May 2006 (UTC)

I think now I come along with what you want ;) The same level of customizability for the "not allowed to edit"-message as for the the "not allowed to view"-message. Got it? How about an extra parameter show-edit (and then of course sth like errorpage-edit). So it would be easily adaptable for every purpose.

Example:

<protect show="none" show-edit="page" errorpage-edit="NoAccess_HideUsers">...</protect> 

--Sirius gd 04:13, 30 May 2006 (UTC)

Btw, there is also a message ProtectedSiteEditing to be displayed on editing. Just corrected the documentation ;) --Sirius gd 04:19, 30 May 2006 (UTC)

Or, you could replace the ProtectedSite error messages with redirection to a known user Template like {{{SectionProtection}}} with optional parameters show='warning'., users='User1,User2', etc. This allow the user to design any custom look they desire for warning messages and protected sections and even allows (through ParserFunctions) the ability to branch to any desired complexity. I successfully modified the PHP code to do just this and it seems to work really well.

Tab for setting rights

It would be very nice if next to the protect-tab would be another one tab Access that gives the ability to control the access for the whole page.

Button for protect tag insert with withard Add a new protect button to toolbar. Some kind of user dialog (protect type, users groups, other possible attributes) is apreciated. --Shtriter 03:53, 30 May 2006 (UTC)

Ideas:

• List of users and groups to select permissions via html-form
• When following a link to a non-existing page from a protected page, the new page is automatically (optional) protected with the same rights. Perhaps, this should only be applied to subpages.
• Subpages get the same rights as their parent-pages (just like access-restrictions on directories)

Implementation thoughts:

• When permissions are changed, the whole article is surrounded by protect-tags
• When starting to edit, the tags are removed and when saving the page, the tags automatically are readded
  • Maybe hashed or cleared? Described above.--Shtriter 03:53, 30 May 2006 (UTC)

Unencrypted diffs

Users that have the right to read an article should see the unencrypted text in the diff. Don't know if this can be done with an extension or if this would need a patch for MediaWiki.

Prohibited and allowed tags

Restricted users must have no right to use some tags, i.e. <protect> (customizable via config and/or attribute). Otherwise we can specify what tags are prohibited for restricted users and what tags are granted.

Pririoty-List

1. PHP4-compatibility
2. Built-in encryption to avoid dependancies
3. Section-edit (Unprotected area)
4. Tab for setting rights
5. Unencrypted diffs