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 Debian bug #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 attachment plugin (see the attachment pagespec info) and the 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 passuser and ip params when it calls pagespec_match would be sufficient. And done, configurable via ?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!