]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blob - doc/todo/per_page_ACLs.mdwn
oh yes, good idea.
[git.ikiwiki.info.git] / doc / todo / per_page_ACLs.mdwn
1 This is about going beyond the current [[ACL]] system and allow not only readonly pages (through [[plugins/lockedit]]) but also read protection, and per page. To quote that other page:
3 >     [[!acl  user=joe page=.png allow=upload]]
4 >     [[!acl  user=bob page=/blog/bob/ allow=]]
5 >     [[!acl  user= page=/blog/bob/ deny=]]
6 >     [[!acl  user=http://jeremie.koenig.myopenid.com/ page=/todo/* deny=create
7 >            reason="spends his time writing todo items instead of source code"]]
8
9 > Each would expand to a description of the resulting rule.
10
11 > a configurable page of the wiki would be used as an ACL list. Possibly could refer to other ACL pages, as in:
12
13 >     [[!acl  user= page=/subsite/ acl=/subsite/acl.mdwn]]
15 I think this would be perfectly possible in Ikiwiki, provided of course the access to the full repository is not allowed, as that cannot be made granular. The way I would see that happen would be by dropping .htaccess files in the right directories and with clever configuration of the virtual host containing the ikiwiki install. Apache has plenty of methods for doing such authentication, and we could simply rely on [[plugins/httpauth/]] for that. *But* there is a key feature of having ACLs per page, or improving the httpauth plugin to have "noread" pagespecs... --[[anarcat]]
17 Agreed with anarcat, I'am experimenting it. Moreover after sketching some kind of "private area" and a "public area" with [[plugins/httpauth/]], I realized in a public page, generated *backlinks* that appears, actually links pages in private. In the end users through backlink navigation will frequently hit HTTP/401 deterring browsing as well as for the admin at false-positive logwatching.  
18 So the plus would be to have a visual display noticing that some link is denied (why not with the reason in a mouseover popup). [[mathdesc]]