User Management Requirements

Advisor/Customer: Eelco Dolstra

GW should support the creation of users for the following reasons:

• To provide access control - not everybody might be allowed to edit or view some pages.

• To provide per-user customisation: preferences, style sheets, etc. (user management should be restricted to provide pointers to the preferred resources; stylesheets are in the rendering and templates package)

• To provide edit traceability - who edited what?

Requirements

Make it possible to create and edit users. The information maintained for each user should be flexible (so that arbitrary properties can be added later on), but should included at least the full name and e-mail address.

Make it possible to create and edit ACLs (access control lists) that define who has the right to do what.

The most important access rights that must be implemented are read and write access. A more interesting access right is who has the ability to modify the access rights (for instance, in the Unix filesystem only the owner of a file can change the access rights, but this is often very limiting). (So maybe the concept of owner should be adapted as well; not just the person who last edited the file. -- EelcoVisser)

ACLs should be per-page; they should not be global to the Wiki. I.e., different parts of the Wiki can have different access controls.

It should be possible to defined recursive ACLs, e.g., if we make /A readable to user Foo, then user Foo should also be able to read /A/B.

Make it possible to create and edit groups (sets of users that can be reffered to in ACLs).

It must not be necessary to login to access/edit the Wiki if allowed by the ACLs (so there should be an "anonymous" user). And login should be prompted only when trying to access a restricted resource.

It would be interesting to be able to form subwikis for which user management is done locally in that subwiki. --EelcoVisser

(Maybe:) Account creation should use an e-mail confirmation scheme to verify that the user supplied a valid e-mail address.

I envision the following milestone releases (subject to change):

Release 1 - user creation

Allow users to be created. User account information should probably just be stored in the Wiki and edited through the normal Wiki mechanisms, for instance, through a Wiki page /Users/Foo for a user named Foo. This makes it unnecessary to create special forms for this purpose.

Release 2 - basic access control

Allow simple, non-recursive ACLs to be defined per-page. Probably setting the ACLs for some page /X should happen by editing /X/ACL.

(Note that it may be problematic to let /X be a page and a directory at the same time, unless we establish some kind of implicit extension scheme. But we (might) also want to use GW to edit arbitrary subversion repositories. -- EelcoVisser)

Use the ACLs to check access to pages.

Release 3 - groups

Allow groups to be created and used in ACLs.

Release 4 - recursive ACLs

Add recursive ACLs.

Release 5 - efficiency?

Perhaps loading and parsing the ACLs for each page access is too slow, so it may be necessary to add caching.

Difficult issues

It's not quite clear how ACLs and versioning should interact. For instance, it will be possible to view old revisions of pages. But should be then use the ACLs in the old revision of the repository, or the current ACLs? The latter is necessary to withdraw or grant access to old revisions of pages. On the other hand, it is not clear how current ACLs should be applied to pages that have been deleted in the current revision.