How about adding ACL? So that you can control which users are allowed to read, write certain pages. The moinmoin wiki has that, and it is something, that I think is very valuable. > ikiwiki currently has only the most rudimentary access controls: pages > can be locked, or unlocked and only the admin can edit locked pages. That > could certianly be expanded on, although it's not an area that I have an > overwhelming desire to work on myself right now. Patches appreciated and > I'll be happy to point you in the right directions.. --[[Joey]] >> I'm really curious how you'd suggest implementing ACLs on reading a page. >> It seems to me the only way you could do it is .htaccess DenyAll or something, >> and then route all page views through ikiwiki.cgi. Am I missing something? >> --[[Ethan]] >>> Or you could just use apache or whatever and set up the access controls >>> there. Of course, that wouldn't integrate very well with the wiki, >>> unless perhaps you decided to use http basic authentication and the >>> httpauth plugin for ikiwiki that integrates with that.. --[[Joey]] >>>> Which would rule out openid, or other fun forms of auth. And routing all access >>>> through the CGI sort of defeats the purpose of ikiwiki. --[[Ethan]] >>>>> I think what Joey is suggesting is to use apache ACLs in conjunction >>>>> with basic HTTP auth to control read access, and ikiwiki can use the >>>>> information via the httpauth plugin for other ACLs (write, admin). But >>>>> yes, that would rule out non-httpauth mechanisms. -- [[Jon]] Also see [[!debbug 443346]]. > Just a few quick thoughts about this: > >* I'm only thinking about write ACLs. As Joey noted, read ACLs need to be done in the web server. >* ACLs are going to be really hard for people with direct access to the revision control system. > Which means that we really only need to define ACLs for web access. >* ACLs for web access can then be defined by the web master. These might not need to be > defined in the wiki pages (although they could be). >* Given the previous two points, can't this be done with the `match_user()` > function defined by the [[plugins/attachment]] plugin (see the [[ikiwiki/pagespec/attachment]] pagespec info) > and the [[plugins/lockedit]] plugin? > > For example, add the following to your config file: > > locked_pages => '!(user(john) and */Discussion) and *', > > would lock all pages unless you're john and editing a Discussion page. > It's a thought anyway :-). -- [[Will]] >> Yes, writing per-user commit ACLs has become somewhat easier with recent >> features. Breaking `match_user` out of attachment, and making the >> lockedit plugin pass`user` and `ip` params when it calls `pagespec_match` >> would be sufficient. And [[done]], configurable via >> [[plugin/lockedit]]'s `locked_pages`. --[[Joey]] I am considering giving this a try, implementing it as a module. Here is how I see it: * a new preprocessor directive allows to define ACL entries providing permissions for a given (user, page, operation), as in:
    \[[!acl user=joe page=*.png allow=upload]]
    \[[!acl user=bob page=/blog/bob/* allow=*]]
    \[[!acl user=* page=/blog/bob/* deny=*]]
    \[[!acl user=http://jeremie.koenig.myopenid.com/ page=/todo/* deny=create
           reason="spends his time writing todo items instead of source code"]]
    
Each would expand to a description of the resulting rule. * a configurable page of the wiki would be used as an ACL list. Possibly could refer to other ACL pages, as in:
    \[[!acl user=* page=/subsite/* acl=/subsite/acl.mdwn]]
    
Any idea when this is going to be finished? If you want, I am happy to beta test. > It's already done, though that is sorta hidden in the above. :-) > Example of use to only allow two users to edit the tipjar page: > locked_pages => 'tipjar and !(user(joey) or user(bob))', > --[[Joey]] > > Thank you for the hint but I am being still confused (read: dense)... What I am trying to do is this: > > * No anonymous access. > > * Logged in users can edit and create pages. > > * Users can set who can edit their pages. > > * Some pages are only viewable by admins. > > Is it possible? If so how?... >>> I don't believe this is currently possible. What is missing is the concept >>> of page 'ownership'. -- [[Jon]] >>>> GAH! That is really a shame... Any chance of adding that? No, I do not really expect it to be added, after all my requirements are pushing the boundary of what a wikiwiki should be. Nonetheless, thanks for your help!