>>>> 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:
for a given (user, page, operation), as in:
<pre>
- \[[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
+ \[[!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"]]
</pre>
Possibly could refer to other ACL pages, as in:
<pre>
- \[[acl user=* page=/subsite/* acl=/subsite/acl.mdwn]]
+ \[[!acl user=* page=/subsite/* acl=/subsite/acl.mdwn]]
</pre>
+
+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!