On Fri, Jul 13, 2012 at 7:58 PM, Alex Eftimiades <[email protected]> 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)=== _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
