[pmwiki-users] a spammed wiki can look like this :-) - protect your wiki!

Patrick R. Michaud pmichaud at pobox.com
Fri Mar 4 18:24:36 CST 2005


On Fri, Mar 04, 2005 at 11:53:12PM +0100, Thomas -Balu- Walter wrote:
> On Tue, Mar 01, 2005 at 06:00:47PM +1100, Nathan Jones wrote:
> > On a related note, I'd recommend using an edit password to protect
> > Main.AllRecentChanges and $Group.RecentChanges. Revoking spam when your
> > history is unreliable is not fun.
> > 
> > Should these be password protected (or edit-proof) by default?
> 
> IMHO yes.

I've thought about it from time to time, but thus far I've always
ended up back at the position that, at least with the current password
interface, the fewer password-protected things there are by default
the better.  People are already confused by the default (and
essentially silent) password protection of things in the Main 
and PmWiki groups, I fear that adding even more "hidden"
passwords into the system will just make a bad situation worse.

However, there's help on the horizon.  Neil Herber, Christian
Ridderström, and others have all made excellent suggestions about
making the password system "more visible" so that there's less
confusion.  Here's some thoughts on these...

PITS 00301 suggests adding output information to the fields
on the page attributes form to indicate which passwords have
been set.  This is a terrific idea; unfortunately the interpretation
of what it means for a password field to be set is handled by the
authorization function (which is site customizable) and not by
the code that sets page attributes.  So, we might not be able to
go quite as far as we might like in providing information in the page
attributes form -- e.g., the attributes form cannot itself
say that a password is being inherited from a group-wide or site-wide
password unless we're willing to impose those semantics on
all PmWiki security schemes (which I'm not willing to do just yet).

Still, knowing if a password has been set is terribly useful,
so we will probably include some sort of visual indicator as to 
which fields have been set with a value and which have not.

PITS 00114 suggests creating a table showing which pages have
which passwords set -- this is also likely to be useful, and 
will probably be a feature of the (:pagelist:) command --
something like (:pagelist fmt=protections :) .

One other item that I'm definitely going to add is to make the
password prompt itself more informative -- instead of simply
prompting for a password, the prompt will also provide the
source of the password.  For example, if it's a group password
that is restricting access to a feature, then the password
prompt will say something like "Password required by group XXX"
or "Password required by site default" instead of simply
"Password required".  This way others (especially administrators)
can see more clearly what the password system is doing and
how to correct it.

We should also fix the phrasing and mechanism used 
to eliminate a password from a page or group in ?action=attr.
Currently the way one removes a password is to enter "clear"
for the password; but as we've seen there are many people who
are confused about what this does or achieves.  (It's also 
terribly English-centric, and I don't think that
internationalizing "clear" is the right answer.)  So, what
I'd like to do is come up with a language-neutral mechanism
for indicating that someone wants an existing password
removed.  (Perhaps the button or marker that indicates that
a password has been set can also be a link to clear it.
Somehow I don't like that.)

While we're at it, we ought to come up with a clearer
mechanism that does what "nopass" does -- i.e., allow
access to do something in spite of a group-wide or
site-wide password that would normally restrict it.

Okay, for many folks it's probably okay to stop reading
here and reply with any comments/suggestions you may have
about the above.  But, for those who want to know my other
plans regarding passwords and authentication,  here's an
expanded description of the little bits and pieces I've
alluded to in other messages over the past few months about
user-based authorization in PmWiki.

A quick review of terminology:  "Authentication" is what
we do to establish a person's identity.  Normally we think of
this as being a "login" procedure.

"Authorization" is how we determine if someone is allowed to
perform a requested operation.  There are many ways to perform
authorization, but authorization does not imply or require
authentication.

PmWiki's current password system performs authorization without
authentication -- a person is allowed to perform an
operation by supplying an appropriate password as an authorization
credential.  In other words, in the current system a person 
doesn't "log in" and thereby establish their identity, they
simply provide a (possibly shared) password that authorizes 
access.  This system is not going away.

What we are going to add is another authorization mechanism --
one based on an authenticated identity.  In this scenario,
a user can either supply an authorization password, or they can
authenticate themselves to the system by "logging in", and then
be granted permission to certain operations based on their
identity instead of having to know a password.

PmWiki will supply a default authentication system that allows
people to establish a login account and password, but sites
will be free to replace (or supplement) this with a custom
module that authenticates based on some other criteria, such
as .htpasswd files, LDAP/Active Directory Services, Novell
Directory Services, RADIUS, or whatever. 

Then, once we have mechanisms to authenticate a person's identity,
the password fields that presently exist will double as
access control lists (ACLs) that authorize specific users
to perform the corresponding actions.  For example, setting
an edit password of "user:Alice,Bob" will mean that only 
Alice and Bob are authorized to edit the page.  Setting
"user:*" will allow any authenticated author to edit,
and "user:-Mallory" will always deny edit access to Mallory.

Of course, ACLs can be set at the group, page, or site
level, thus

    $DefaultPasswords['edit'] = 'user:Alice,Bob';

in config.php will set the site default to allow only Alice 
and Bob to edit pages.  Of course, the site default can 
still be overridden by passwords set at the per-group
or per-page level.

The password field can contain combinations of both ACLs
and authorization passwords, thus setting an edit password of:

    user:Bob mysecret user:-Mallory

will mean that Bob is granted access, as well as anyone
who knows the password "mysecret", but never Mallory.
(If Mallory is logged in and knows the authorization password, 
she is still denied access to the page -- she must log out in
order to edit the page.)

Eventually I know some sites will want to be able to establish
groups of authenticated users and be able to specify access
controls such as "group:editors" or "group:admins", but I'm
saving that for a later revision.  I just want to get the
basic user capabilities in place first and tested before I
add yet another layer of complexity.

Okay, that's my treatise on plans for PmWiki passwords.  Now
all I have to do is implement the darn thing.  :-)

Pm



More information about the pmwiki-users mailing list