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?
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
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
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.
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