[Pmwiki-users] PmWiki password puzzles

Patrick R. Michaud pmichaud
Mon Aug 30 06:57:43 CDT 2004


This message talks a bit more about PmWiki's passwording system, and
has two questions ("Q1" and "Q2" below) on which I'm seeking input.
For purposes of this message, I'm temporarily setting aside the issue
of user-based authorization schemes, which I'm also working on.

PmWiki's authentication system has a couple of annoyances that 
I'd like to address.  First, for historical reasons PmWiki's 
default authentication mechanism has been to use HTTP based 
authentication.  Unfortunately, this tends to work only in 
environments where PHP has been built as an Apache module;
i.e., it generally doesn't work if PHP is running as a CGI script or
other environments where the HTTP authentication information is not
available to PHP.  It also fails on systems where the PmWiki script
is being otherwise protected by Apache (e.g., a .htaccess file).

The solution to this second problem has typically been to use session-based
authentication, via the sessionauth.php script.  However, since
session-based authentication works "everywhere", while HTTP Basic
authentication works only on selected systems, I'm thinking I should
just switch the distribution to use session-based authentication
by default and provide HTTP Basic authentication as an option.  I think
would eliminate a lot of frustration and mail from people who are 
having trouble getting passwords to work on their systems.

*** Q1: Any one have comments in favor of or against switching to session-based
authentication as the default?

Second, in response to John Rankin's earlier message (and to better support
user-based authorization) I'm changing the authentication system 
so that a page can have multiple passwords for each access level.  
However, there's still an annoyance with pages that have both a read
and an edit password set-- an author editing such a page has to alternate 
between entering the edit and the read password at each post, which 
is annoying.  We can "solve" this annoyance by either:
  1. Leave things as they are--someone wanting to avoid the alternating
     edit+read password problem in pages would then set the edit password
     in both the edit and read password fields.
  2. Have the system assume that a person who knows the edit or
     attribute password is automatically given read permission to a page
     without having to explicitly enter or know the read password.
  3. Have the system cache all of the passwords that have been entered
     during a browser session, and test each page request against the
     set of passwords (so that a user would only have to enter each
     unique password once per browsing session).

#1 has the advantage of a simpler implementation (not important) and
preserving the ability to force authors to be aware of the separate
read+edit passwords; the disadvantage is that a person setting a password
has to know to enter the edit password in both the "read" and "edit"
password fields.

#2 has the advantage of handling a great many things automatically, with
the possible disadvantage that it's not possible give someone the ability
to edit or change a page's attributes without also giving read permission
(probably not common).

#3 has the advantage of being able to automatically keep track of all the 
passwords an author has used during a session, greatly reducing the number
of password prompts encountered; but there may be a disadvantage in it
becoming "too seamless" so that authors forget which pages are protected
where.

#2 and #3 above are probably not mutually exclusive, so they can
both be implemented or made as options that can be enabled or disabled.

*** Q2:  But my question is, what should be PmWiki's "default" setup
in the distributed version?

Thanks.

Pm



More information about the pmwiki-users mailing list