git.oblomov.eu Git - ikiwiki/blob - doc/todo/ACL.mdwn

   1 How about adding ACL? So that you can control which users are allowed
   2 to read, write certain pages. The moinmoin wiki has that, and it is
   3 something, that I think is very valuable.
   4
   5 > ikiwiki currently has only the most rudimentary access controls: pages
   6 > can be locked, or unlocked and only the admin can edit locked pages. That
   7 > could certianly be expanded on, although it's not an area that I have an
   8 > overwhelming desire to work on myself right now. Patches appreciated and
   9 > I'll be happy to point you in the right directions.. --[[Joey]]
  10
  11 >> I'm really curious how you'd suggest implementing ACLs on reading a page.
  12 >> It seems to me the only way you could do it is .htaccess DenyAll or something,
  13 >> and then route all page views through ikiwiki.cgi. Am I missing something?
  14 >> --[[Ethan]]
  15
  16 >>> Or you could just use apache or whatever and set up the access controls
  17 >>> there. Of course, that wouldn't integrate very well with the wiki,
  18 >>> unless perhaps you decided to use http basic authentication and the
  19 >>> httpauth plugin for ikiwiki that integrates with that.. --[[Joey]]
  20
  21 >>>> Which would rule out openid, or other fun forms of auth. And routing all access
  22 >>>> through the CGI sort of defeats the purpose of ikiwiki. --[[Ethan]]
  23
  24 >>>>> I think what Joey is suggesting is to use apache ACLs in conjunction
  25 >>>>> with basic HTTP auth to control read access, and ikiwiki can use the
  26 >>>>> information via the httpauth plugin for other ACLs (write, admin). But
  27 >>>>> yes, that would rule out non-httpauth mechanisms. -- [[Jon]]
  28
  29 Also see [[!debbug 443346]].
  30
  31 > Just a few quick thoughts about this:
  32 >
  33 >* I'm only thinking about write ACLs.  As Joey noted, read ACLs need to be done in the web server.
  34 >* ACLs are going to be really hard for people with direct access to the revision control system.
  35 >  Which means that we really only need to define ACLs for web access.
  36 >* ACLs for web access can then be defined by the web master.  These might not need to be
  37 >  defined in the wiki pages (although they could be).
  38 >* Given the previous two points, can't this be done with the `match_user()`
  39 > function defined by the [[plugins/attachment]] plugin (see the [[ikiwiki/pagespec/attachment]] pagespec info)
  40 > and the [[plugins/lockedit]] plugin?
  41 >
  42 > For example, add the following to your config file:
  43 >
  44 > locked_pages => '!(user(john) and */Discussion) and *',
  45 >
  46 > would lock all pages unless you're john and editing a Discussion page.
  47 > It's a thought anyway :-).  -- [[Will]]
  48
  49 >> Yes, writing per-user commit ACLs has become somewhat easier with recent
  50 >> features. Breaking `match_user` out of attachment, and making the
  51 >> lockedit plugin pass`user` and `ip` params when it calls `pagespec_match`
  52 >> would be sufficient. And [[done]], configurable via
  53 >> [[plugin/lockedit]]'s `locked_pages`. --[[Joey]]
  54
  55 I am considering giving this a try, implementing it as a module.
  56 Here is how I see it:
  57
  58   * a new preprocessor directive allows to define ACL entries providing permissions
  59     for a given (user, page, operation), as in:
  60
  61     <pre>
  62     \[[!acl user=joe page=*.png allow=upload]]
  63     \[[!acl user=bob page=/blog/bob/* allow=*]]
  64     \[[!acl user=* page=/blog/bob/* deny=*]]
  65     \[[!acl user=http://jeremie.koenig.myopenid.com/ page=/todo/* deny=create
  66            reason="spends his time writing todo items instead of source code"]]
  67     </pre>
  68
  69     Each would expand to a description of the resulting rule.
  70
  71   * a configurable page of the wiki would be used as an ACL list.
  72     Possibly could refer to other ACL pages, as in:
  73
  74     <pre>
  75     \[[!acl user=* page=/subsite/* acl=/subsite/acl.mdwn]]
  76     </pre>
  77
  78 Any idea when this is going to be finished?  If you want, I am happy to beta test.
  79
  80 > It's already done, though that is sorta hidden in the above. :-)
  81 > Example of use to only allow two users to edit the tipjar page:
  82 >       locked_pages => 'tipjar and !(user(joey) or user(bob))',
  83 > --[[Joey]]
  84
  85 > > Thank you for the hint but I am being still confused (read: dense)...  What I am trying to do is this:
  86
  87 > >  * No anonymous access.
  88 > >  * Logged in users can edit and create pages.
  89 > >  * Users can set who can edit their pages.
  90 > >  * Some pages are only viewable by admins.
  91
  92 > > Is it possible?  If so how?...
  93
  94 >>> I don't believe this is currently possible. What is missing is the concept
  95 >>> of page 'ownership'. -- [[Jon]]
  96
  97 >>>> 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
  98  should be.  Nonetheless, thanks for your help!