00748: Merge AuthUser with UserAuth?
Description: (I moved this topic from the AuthUser page since I think it's a case for the PITS. --Henning June 02, 2006, at 10:26 AM)
It'll be a good adition to have a permanent cookie in AuthUser so you don't have to enter passwords every browser session. And apart from changing permissions from attributes or config files, a method like "web based admin control" will be exellent (defining users permission in one page).
I think the best feature of User Auth is the web based admin control, especialy the new ability to incorporate groups with ver 0.70 (I know auth user can do this, but much easier with a web panel). I don't like having to alter my config file every time a new user needs to be added. Auth User is far more stable if you ask me. I find it works more than it doesn't, which is not always the case with User Auth. Also, User Auth is more suited to larger wiki's because it offers quick and easy control over access, while Auth User is simple for a hand full of passwords. Just my two cents, Pm :) As a side note, is it possible to incorporate which groups you don't want included in addition to ones you can? An example, it would be nice to allow read/ edit abilities for all but a few groups with out having to set different permisions manually. Say, you want members of an organization to edit most groups, but not staff or other private groups. I think it would be helpful to have something like noread_Staff.HomePage or noedit_Personal.Stuff. -Matt
The other recipe which is very similar to this has its own strengths, including a nice login form, and a form for adding and managing users. Also, I wonder if CMSLike can be used with this recipe as well as it works with UserAuth. I'd like to see the best of both combined into a single recipe. shi
Feature request: web-based management panel that allows admins and users to add accounts, self-register, configure permissions, and change passwords. Requiring a wiki admin to edit the config file or run 'htpasswd' from a shell command line negatively limits handing off the admin task to others. Even with the limited implementation in UserAuth, it offers a huge advantage for bigger deployments. It would be great to have something comparable or better in AuthUser. --gt
self registration with separate activation by the administrator. --SDV
Thanks, Patrick - the features I would like most to see are:
- support for group-based permissions: I do prefer the way AuthUser supports access permission definitions for individuals (i.e. defining the permissions 'page-centric' rather than 'user-centric', although it would be nice somehow to be able to generate a report for any user or group of what permissions they have throughout the site), and think extending the interface could be as simple as adding the syntax group:groupname in addition to id:username for specifying access in attr pages - of course there would also need to be support for group definitions, but there is already a spec for that, htgroups (UserAuth doesn't do this either yet)
Group definitions are available in 2.1.beta8.
- a web-based management panel, and ability for users to change their own passwords (UserAuth has something for this)
- a recipe like (or based on) CMSAuth that works with AuthUser
--shi- support for group-based permissions: I do prefer the way AuthUser supports access permission definitions for individuals (i.e. defining the permissions 'page-centric' rather than 'user-centric', although it would be nice somehow to be able to generate a report for any user or group of what permissions they have throughout the site), and think extending the interface could be as simple as adding the syntax group:groupname in addition to id:username for specifying access in attr pages - of course there would also need to be support for group definitions, but there is already a spec for that, htgroups (UserAuth doesn't do this either yet)
June 3, 2006 - I would definitely like to see AuthUser and UserAuth merged into one recipe. The UserAuth approach is far more intuitive than AuthUser because everything is performed from one page. I would also like to see LDAP authentication added to UserAuth, and more details about how someone could use UserAuth groups with http authentication (where an LDAP query can be used to lookup the authenticated user and obtain the users display name to populate the Author field. --GaryV
July 12, 2006 - I would (also) like to see:
- web-based permission management
- easy handing-off admin tasks by a granting scheme like in MySQL
- report for any user of what permission they have
- self-registration (extensible by check against automated registration by bots)
--ThomasP
July 22, 2006 - Patrick, thanks for the effort - I'm new to PmWiki but I think it is a great piece of software.
I would like to comment about incorporating UserAuth into AuthUser: I think any incorporation will lose the main feature of UserAuth, its user-centeredness. I think many users that have chosen UserAuth did this because of this standard (and thus more intuitive) way of assigning rights. Reverting back to the "other" view would surely be dissatisfying for them. (Note that this is a question of personal taste/perspective rather than a question of realizability of certain permission configurations.)
A point why I think UserAuth is actually better (at the moment) is that it is more flexible when one wants to add further permission levels or change the action-to-permissionlevel mapping. Ex.: say I want to make the history for a page visible only for persons with more then "edit" rights. Using UserAuth I would add
$HandleAuth['diff'] = 'history';
to my config and then add an ability "history_page-MyFoo.BarPage" to the abilities list. That's all. Using AuthUser we are (as far as I see and at the moment) restricted to the permission levels "read", "edit", "upload", "attr". (This is a result though of the fixed password fields on the ?action=attr page and could be resolved by changing this page to a fully-editable wiki page, with sections corresponding to [possibly user-defined] permission levels.) It would be desirable to keep the action-to-permissionlevel mapping at least configurable and extendable on a cookbook recipe basis.
In this connection I would propose to further extend the use of explicit action identifiers, e.g. "search", "download" etc., which then can be mapped to levels (might be already done in recent pmwiki versions). This would (or has alrady) obsoleted or streamlined many single cookbook recipes involving permission issues (cf. Cookbook.SecureAttachments)
Back to the original point, ideally would be to have a single authentication system which can be run both user or page centric (admin decides when he starts to assign permissions; this means that there are no two different systems cascaded as currently in UserAuth). (Note that the difference lies in the perspective, so one perspective always can be transformed into an equivalent version of the other persepective.) As I think that an implementation of this would be (unnecessarily) hard, I would even consider furthering two different but functionally equally rich (kept) authentication systems.
ThomasP (pmwiki 2.1.beta25, UserAuth ver 0.70)
22/07/2006 - Just an idea of how a system might look that allows for both user and page centric assignment of permissions: Say we have one site-global permission file, which can take entries like this:
*read_group-PageGroup1: id:user1, id:user2, password2, id:admin *edit_group-PageGroup1: id:user3, ... *upload_group-PageGroup1: id:admin, ... ... *read_page-PageGroup2.MyPage1: id:user3, password3
This is a page-centric view in the standard pmwiki style. Note that we do not need "attr" fields anymore. Note also that we have a good overview over permissions. Besides we can easily extend this to new permission levels.
Now on the other hand, the same wiki file would allow to take up values like
*id:user1: read_group-PageGroup1, *id:user2: read_group-PageGroup1 *id:user3: edit_group-PageGroup1, read_page-PageGroup2.MyPage1 *id:admin: read_group-PageGroup1, upload_group-PageGroup1
which would be a user-centric view (in the style of the current UserAuth admin report) of the same (!) system. One should ponder a bit whether to allow both views in one file but the admin could also decide at the beginning for one view.
Besides this file there could be one defining action-to-permissionlevel mappings, like:
read: browse, read, search, diff, download edit: edit upload: upload ...
That is just a basic outline about how to generalize the current system to fit both views. Many details could be reasoned about here. Maybe it is also a bit of overkill.
There is a lot of functional overlap in UserAuth and AuthUser, so it would be nice to see them merged in some way. I'm currently running a farm, in which I use separate wikis to keep certain information logically separate. Since I am trying to run various courses via the wikis, and since it is not appropriate for students to edit every page in a wiki (mainly I want to keep things like assignment pages intact), one of the big challenges I face is using the various authentication privs in a rational way. Also the gaps in various recipes make it challenging to figure out exactly how to do this. Specifically, I would like
- single point-of-access authority for admin over all the wikis
- separate privs defined for each wiki -- not merely group-based as currently exists
- users able to change their own passwords (excellent feature of UserAuth)
- easily inspected privs for all groups/pages (by admins, at the very least) for pages, groups, wikis
Some of these things can be done more-or-less but in general admin considerations for wiki farms are not well supported by either recipe. UserAuth is a bit better, mainly because it centralizes administration of privs, and permits users to change passwords. The last point would really help trouble-shooting privs problems like I have now, when authentication seems to break.
paolillo [snail] indiana [period] edu
To add a (maybe) final comment (I hope I speak for the majority): it has turned out that merging the two then former solutions (= going a common way) would not satisfy everyone as it would be desired, so keeping the two paradigms intact and each in itself consistent seemed a better resolution.
I have developed the successor of UserAuth with the aim to clear up all major shortcomings of that recipe while inheriting its general view of organizing privileges which seemed to me worth to be preserved considerably.
The current form of UserAuth2 (2.1-beta0) has not a special support for wiki farms (like centralized administration for all wikis), but this can still be tackled if there should be sustained interest.
ThomasP December 16, 2007, at 11:38 AM