[pmwiki-users] How to password protect read/write access to everything in a category?

[Peter Bowers]

On Fri, Jul 13, 2012 at 7:58 PM, Alex Eftimiades
<alexeftimiades at gmail.com> wrote:
> I was looking for an easy way for editors to password protect something so
> that only other editors could see/edit it. I tried making a password
> protected group, but that quickly became an organizational hindrance. I want
> this to be very easy for editors, so the logical thing seemed to be to
> password protect a category with the editors' password, then just have
> editors tag articles in the password protected category. The problem is that
> I have no idea how go about doing this. Could anyone help me password
> protect a category or come up with a better idea to accomplish the same
> thing?

I can think of 4 ways to do this:

(1) Copy and modify the security mechanism of pmwiki so that it looks
for the presence of a given category as part of the way it checks
whether someone is authorized.  Difficulty: 9/10.  NOT recommended.

(2) Write an additional filter and place it in $EditFunctions to be
used by UpdatePage().  It would simply check the new text for the
presence/absence of a given category and add or strip out a password
based on this.  Difficulty: 3/10 (as long as you don't have to worry
about any other per-page passwords)

(3) In config.php simply check if the current $action is 'edit' and,
if so, set or unset a site-wide edit password based on the
presence/absence of the given category in the text.  Difficulty: 2/10
(if you run into caching problems because you're reading the page
during config.php processing then this may move up to 6 or even 8 out
of 10)

(4) Rather than using the category solution at all, simply set up a
form which you can put in the page header or footer.  This form would
be visible only to users with appropriate authorization and it would
be a simple toggle button (protect / unprotect page).  Difficulty:
4-5/10 (or even easier if you've worked with forms in pmwiki before)

I would suggest #4 as it avoids getting into the potentially thorny
areas of authorizations, caching, etc.

I'm not sure if pmform or fox forms supports setting passwords -- if
so then that would ease things quite a bit.  WikiSh supports it, but
it's probably not worth the learning curve unless you're going to do
more than just this project...

-Peter

Some *thoughts* on implementation -- much of this is syntactically
incorrect, far less tested...  Just to give you an idea.

Site.PageHeader:

===(snip)===
(:if authid:)
>>float right<<
(:input form http://url/to/your/formscript.php method=GET:)
(:input hidden name=n [I forget how to make the default here...]:)
(:if1 equal "{$Protected}" 1:)
(:input submit name=unsetpw label="Unprotect Page":)
(:else1:)
(:input submit name=setpw label="Protect Page":)
(:if1 end:)
(:input end:)
>><<
(:if end:)
===(snip)===

Oh, on second thought, it would be even better putting this into
PageActions -- better for screen real estate, logically/intuitively,
etc.

in config.php:

===(snip)===
# See Cookbook/OpenPass for an example how to set a PV based
# on the presence/absence of a password.  Your conditional in PageActions
# or PageHeader will use this PV to determine whether to offer
# "Protect Page" or "Unprotect Page" or etc.  I called it {$Protected} above.
===(snip)===

in formscript.php:

===(snip)===
# Rough (!!) pseudo-code for handling the form
if (@$_GET['setpw']) {
   $page = RetrieveAuthPage($pagename, 'edit'); // make sure we have auth
   if ($page['passwdedit']) ... or not ... yada, yada ...
      $page['passwdedit'] = encrypt($myStandardPassword); // add passwd
   UpdatePage(args); // save the page
   // fix the URL to get rid of $_GET['setpw'] and anything else that
should be dumped
   Redirect(args); // redirect back to current page (n) without $_GET values
                           // now that the page password has been set
} elseif (@$_GET['unsetpw']) {
   // do the same kind of stuff, but you're getting rid of the passwd
rather than
   // adding it...
}
===(snip)===