BobMoore
In keeping with PmWiki/PmWikiPhilosophy #3:
I have a small number of users. My wiki now uses .htpasswd file authentication built into Apache. No need just yet for a WikiFarm. I do use Cookbook/BasicLogout on my server though. Users share wiki.d but as far as I know they cannot see each other except as specified in local/config.php. I added the code below to pmwiki/local/config.php.
Fill in the contents of the edit page's "Author" field with a username entered from the password prompt:
if (@$_SERVER['PHP_AUTH_USER'])
$Author = $_SERVER['PHP_AUTH_USER'];
Use the username at login to define $GroupNamePattern by user. This may not be the best way for PmWikis with many users, but it may suit the needs of PmWiki admins who maintain .htaccess in the pmwiki directory with a password file above their htdocs directory:
if ($_SERVER['PHP_AUTH_USER'] == 'bob') {
$GroupNamePattern = '(?:PmWiki|Main|Shared|Bob)';
}
if ($_SERVER['PHP_AUTH_USER'] == 'userone') {
$GroupNamePattern = '(?:PmWiki|Main|Shared|UserOne)';
}
if ($_SERVER['PHP_AUTH_USER'] == 'usertwo') {
$GroupNamePattern = '(?:PmWiki|Main|Shared)';
}
Can the same thing be achieved with still less code?
To me, it is worth making the Author field tamper proof after log-in, by printing the username in place of a username input form field. Maybe this is something that can be added in a future release? It might use a boolean called something like AllowAuthorChanges?
--BobMoore
I'm not sure I'm following exactly what is being requested here, so I'll try to explain PmWiki's perspective. On one hand, I think that you may be commenting about the fact that PmWiki sometimes re-requests passwords on the same site for different groups--even if the password is the same. This is really a function of the way that browsers associate passwords with urls, i.e., when you switch pages from group X to group Y, the browser thinks you're in a different location and so it prompts again for the password. It's not something that PmWiki enforces or controls. (I'm going to check into the HTTP Basic protocol a bit further to see what I might be able to do about this so that browsers recognize the entire site instead of just the groups.)
You can also circumvent this problem by using the scripts/sessionauth.php script provided with PmWiki, which doesn't make use of the browser's authentication features. t In a larger sense, there are many group environments where having a shared password makes a lot more sense than requiring per-user authentication. For example, in the research projects and departments where I used to work, it was much easier to just tell everyone involved that the password is "x" than it was to require everyone to create a user account and password and facilities for recovering/resetting lost passwords, not to mention expiring old accounts or worrying about password security on the server.
And even if PmWiki does provide a way to keep user accounts for authentication, that still doesn't resolve the entire issue. Many (if not most) sites will want some users to be able to edit certain pages but not others, thus in addition to providing a way of associating usernames (identification) with passwords (authentication), there also has to be a way of saying which users are allowed to perform which actions on which pages (authorization). Normally this is done with features such as access control lists, which can get pretty unwieldy at times. I haven't seen an access control system I like.
For these reasons, PmWiki takes the approach of providing a very simplistic passwording mechanism that works for small groups of users and meets the needs of a large number of environments, while providing hooks to allow custom authentication/authorization routines to be used instead for those environments that need something different. For example, some PmWiki sites make use of centralized organization-wide databases for authentication. I don't see anything wrong with having a user-based authentication model, I just didn't want to impose that model (and the administrative setup and maintenance overhead it requires) on PmWiki administrators and installations where it may not be useful or appropriate.
I'm quite open (and willing) to design and implement a Cookbook module for user-based authentication, but nobody's satisfactorily answered the authorization issue yet (i.e., how do I determine which actions user U is allowed to perform on pages/groups X, Y, and Z?). I'm also willing to help people design custom authentication modules, but in keeping with PmWiki/PmWikiPhilosophy #3, I normally only do that after specific needs are identified (i.e., when someone can indicate fairly precisely how it ought to work). :-)
This information should probably go in a Development page somewhere. :-)
--Pm
A programmer friend suggested to me that a way it could work would be to have site-wide authentication with resource-based authorisation. That is, you have the whole site under the same "realm" (that's AuthName business with Apache), and then the Wiki stuff itself checks who the user is and whether they can scribble over a given page.
I have been reading about Apache and testing a new .htaccess file in the same directory as pmwiki.php on my server. But how to allow specific users to access only specific wiki groups and thus build up the pages they see and edit?
The environment I am working in has very few users with specific requirements for grouped resources to display in their wiki pages. Perhaps then, moving to a Development.WikiFarm -based approach rather than a Group-based one will be a good thing. With farms, is per-user authentication not a great deal easier from the user's point of view?
Example: a user authenticates using a PHP script or an .htaccess file. Their permissions are passed to some PHP script that uses the information to determine which text areas on a page will include an Edit link, or be shown at all. Other areas of text cannot be changed.
It seems pmWiki more or less has this already with the sidebar and main wiki parts of the page both being editable and separate.
Yes, PmWiki already has most of what you need. But the key question remains how to allow specific users to access only specific wiki groups--the authorization problem.
Per-user authentication is neither harder nor easier in a Development.WikiFarm -based approach.
You can already put the entire site under the same realm--simply change $AuthRealmFmt in config.php to be
$AuthRealmFmt = '$WikiTitle';
and the entire wiki will be in the same realm. (The default is set to '$WikiTitle - $Group', which places each group in a different realm.) dddddd
--Pm