[pmwiki-users] pmwiki-2.0.beta29 out, needs testers and feedback

[Patrick R. Michaud]

Hello, all, I've just released PmWiki 2.0.beta29, which contains the
preliminary support for user-based authorization semantics.

This release incorporates some significant changes in the authorization
and page storage code, so production-level sites might want to wait for
any new bugs to found and fixed before upgrading.  Or, go ahead and
upgrade but be prepared to revert back to beta28 or earlier if you
start to notice problems.

However, I do need lots of testers for the new code in this release,
of which there's a fair bit.  Thus, I'd greatly appreciate any
help people can provide with testing the new system and suggesting
improvements.  I'm particularly looking for suggestions about how
the interfaces can be made easier to understand.

Testing can also take place in the Test group on pmwiki.org (e.g.,
http://www.pmwiki.org/wiki/Test/Test).  Since the biggest changes to
be tested are in PmWiki's authorization semantics, I've set the
Test group's "admin" password to "quick" so that anyone can bypass
any passwords that someone else may have set in that group's pages.

First, I'll cover improvements in the basic authorization system itself.
The Page Attributes form (reached via ?action=attr and used to set
passwords) has been improved so that it's now possible to see which 
passwords have been set, and if those passwords are coming from the 
group or site defaults.  For an example, see
http://www.pmwiki.org/wiki/Test/AttrExample?action=attr .  These
prompts are not yet internationalized -- I want to get the english
interface finalized first and then we'll make the i18n strings for it.

Multiple passwords (separated by spaces) can now be set on pages and groups,
thus entering "one two" for an edit password will means that either "one" or
"two" will be accepted.  Because of this, passwords cannot contain
spaces (I hope this won't be a major loss -- let me know if it will).

The password request field now appears within a normal skin layout 
(i.e., with header, sidebar, footer); previously requests for 
passwords were undecorated forms that appeared alone in the browser
window.

There is an (:if auth ...:) conditional markup available for 
processing depending on the current authorizations in effect.  For
example, one can create a bullet list with
    
    (:if auth read:)* [[View page -> {$Name}?action=browse]]
    (:if auth edit:)* [[Edit page -> {$Name}?action=edit]]
    (:if auth upload:)* [[Attachments -> {$Name}?action=upload]]
    (:if auth attr:)* [[Page Attributes -> {$Name}?action=attr]]
    (:if auth admin:)* You're logged in as admin
    (:ifend:)

and only those items corresponding to the user's current authorizations
will appear.  This should be very useful in creating action buttons.
(There's also an easier way to test a page's authorizations in PHP 
-- more on this in another message.)

Alone, these are fairly significant enhancements.  However, this
release goes a step further by providing initial support for
user-based authentication and authorization.  At present the
only supported form of authentication is to make use of whatever 
is provided by the webserver in the REMOTE_USER variable
(usually achieved with .htaccess/.htpasswd files -- more
on this below), but it's highly extensible so that nearly any 
authentication mechanism can be used, including custom .htpasswd files,
user registration, LDAP/Active Directory Server, and others.

But, assuming there's already some mechanism in place for identifying
and authenticating someone, pages can specify a password field of
"id:xyz", which means to allow only user "xyz" the specified
access.  For example, specifying an edit password of "id:alice"
means that only user "alice" (and the admin) is allowed to edit the 
page.  Multiple ids can be specified as either "id:alice,bob,carol"
or "id:alice id:bob id:carol".  The special value "id:*" is used
to mean any authenticated user, and users can be excluded via the
minus sign, as in "id:-eve,*".

User-based authentication can completely coexist and mix freely with 
password-based authentication, thus an edit password of 
"id:alice glorp" will allow Alice and anyone who knows the
password "glorp" to edit the page.  

Now then, how to activate user-based authorization?  Well, that's
the part I need to work on next.  If you already have an authorization
system in place for your webserver (e.g., through the use of .htaccess
and/or .htpasswd files), then you may be able to simply do

    include_once('scripts/httpauth.php');

and PmWiki will automatically begin grabbing authentication information
from the REMOTE_USER environment variable when it exists.

For others, I'm presently working on three modules:
   1. A simple extension to perform authentication against ids/passwords
      held and maintained in a .htpasswd file (i.e., bypassing the 
      webserver's authentication but re-using existing tools)
   2. A registration system to allow users to create an account and
      passwords that are held in users' profiles pages
   3. An system for sites that already have single-sign-on systems 
      (e.g., LDAP, Active Directory, or RADIUS servers)

These should be available shortly.  #1 and #3 will probably occur
first; #2 is a fair bit more work because of the need to develop
a user-registration form and password recovery system.

Again, I'm looking for feedback, testing, suggestions, and questions
so that I can improve the interfaces for this new system.

Pm