1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
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]]
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:
<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
reason="spends his time writing todo items instead of source code"]]
</pre>
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:
<pre>
\[[!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?...
|