bd71e8011838b19cc90cb8637af60e16b25a3a12
[ikiwiki.git] / doc / todo / Zoned_ikiwiki.mdwn
1 [[!toc levels=3]]
2
3 # Zoned ikiwiki
4
5 ## The idea
6
7 The idea behind this would be to have one ikiwiki behave as a dynamic private wiki in a specified area
8 and a more static publiczone wiki.
9
10 ## Use cases
11
12 This can be more or less difficult depending on the use case.
13
14 ### Purely static public zone with a single, controlled-access inward zone
15
16 For this case, only a known set of people are authorized to see the inward zone
17 or edit anything. Everybody else sees only the public zone. This use case is mostly
18 easy to handle now, as long as access to things like the `recentchanges` page and
19 repository browser are not granted for the public zone. In particular, the features
20 that allow information exposure via edit access are not of concern in this case.
21
22 ### Static public zone, more than one controlled inward zone
23
24 In this case, the known, controlled set of people with special access are divided
25 into groups with access to different (or overlapping) zones. The public still sees only a static zone.
26
27 Here, some of the harder issues, like information disclosure via edit access, do apply,
28 but only to members of the known, controlled groups. How much of a problem that is
29 depends on _how sensitive_ the information is that each group might reveal from another
30 zone. The rcs logs will show when a page has been edited to contain an [[ikiwiki/directive/inline]]
31 directive or other trick to reveal information, so if it is enough to treat the trusted users' conduct
32 as a management issue ("don't do that, please") then the risks can be acceptable in this case.
33
34 ### Public zone allows contribution/editing by external users
35
36 This case is the most difficult to cover at present, and probably shouldn't be attempted
37 without solutions to most or all of the **obstacles** identified here. 
38
39 ## Implementation techniques
40
41 What is ready /can be done:
42
43 * We already can more or less do this for example with [[httpauth|/plugins/httpauth/]], *.htaccess* files and a proper *httpauth_pagespec*
44 yet at the cost of maintaining two different user/pass logbase (native ikiwiki signin)
45 * Furthermore we can [[lockedit|plugins/lockedit/]] some pagespecs, ie in the public zone.
46
47 ## Obstacles
48
49 A number of ikiwiki features aren't (yet) designed with zoning in mind,
50 and it will take some effort both to identify them all, and to think out how they
51 could be addressed. This section invites brainstorming of both kinds.
52 This might eventually merit a separate page [[Zoned ikiwiki obstacles]]
53 but I'll begin it here.
54
55 Note that not all of these issues will be problems for all **zoned ikiwiki use cases**.
56
57 ### Backlinks
58
59 What is problematic is when you link a public page in a private page : 
60 a backlink will be generated from the public page to the private page.
61
62 As noted in [[per_page_ACLs]] in the end users through backlink 
63 navigation will frequently hit HTTP/401 deterring browsing as well as for the admin at false-positive logwatching.
64
65 One can radically [[disable backlinks feature|todo/allow_disabling_backlinks]] but then no more neat backlink navigation that
66 is really good to have in both area.
67
68 Another way of just preventing this backlink leak in that case would be sufficient via i.e a *privatebacklinks* config and
69 a patch like this one [[!toggle id="backlinkpatch" text="(show)"]].
70
71 [[!toggleable id="backlinkpatch" text="""
72 Comments are welcome.
73
74 [[mathdesc]]
75
76
77 <pre>
78 diff --git a/IkiWiki.pm b/IkiWiki.pm
79 --- a/IkiWiki.pm
80 +++ b/IkiWiki.pm
81 @@ -294,6 +294,14 @@ sub getsetup () {
82                 safe => 1,
83                 rebuild => 1,
84         },
85 +       privatebacklinks => {
86 +               type => "pagespec",
87 +               example => "",
88 +               description => "PageSpec controlling which backlinks are private (ie users/*)",
89 +               link => "ikiwiki/PageSpec",
90 +               safe => 1,
91 +               rebuild => 1,
92 +       },
93         hardlink => {
94                 type => "boolean",
95                 default => 0,
96 diff --git a/IkiWiki/Render.pm b/IkiWiki/Render.pm
97 --- a/IkiWiki/Render.pm
98 +++ b/IkiWiki/Render.pm
99 @@ -52,7 +52,8 @@ sub backlinks ($) {
100                         $p_trimmed=~s/^\Q$dir\E// &&
101                         $page_trimmed=~s/^\Q$dir\E//;
102                                
103 -               push @links, { url => $href, page => pagetitle($p_trimmed) };
104 +               push @links, { url => $href, page => pagetitle($p_trimmed) }
105 +               unless defined $config{privatebacklinks} && length $config{privatebacklinks} && pagespec_match($p, $config{privatebacklinks}) && !pagespec_match($page, $config{privatebacklinks}) ;
106         }
107         return @links;
108  }
109
110 </pre>
111 """]]
112
113 In use cases where the main concern about backlinks is only the bad user experience when links are
114 shown that lead to access denial when clicked, a workable
115 solution could be to make the backlinks `div` invisible in `local.css`.
116
117 ### recentchanges page
118
119 An accessible `recentchanges` page can include links to changes to pages
120 that should not be accessible. Even if the links cannot be followed, the
121 existence of the pages and their edit history are leaked. If rcs integration
122 is configured, those links on the `recentchanges` page can leak complete contents
123 through the **rcs browser**.
124
125 It can be helpful to generate separate `recentchanges` pages for different zones.
126 The [[plugins/recentchanges]] plugin already allows this--a `recentchanges` page
127 can be created anywhere, just by using the `recentchanges` directive
128 with the right [[ikiwiki/PageSpec]] for the zone it should cover--except that it cannot yet
129 be configured to generate a different `recentchanges` link destination into pages
130 in different zones. So, it would be helpful if its configuration could allow multiple
131 `recentchangespage` values, paired with `PageSpec`s for the pages on which they
132 should be used.
133
134 ### rcs browser
135
136 If the repository browser is accessible, potentially all content can be exposed.
137 Even if links to the repository browser are not generated into public wiki pages,
138 if a user can obtain or guess the repository browser URL and construct arbitrary
139 requests, information can be revealed.
140
141 Solutions could involve authnz features of the revision control systems themselves
142 and their associated repository browsers; for example, `svn` supposedly has such
143 features, and recent versions of `viewvc` supposedly honor them. But such features
144 may not be available for every rcs, and where they are available, they'll have to
145 be configured separately and differently from ikiwiki itself. They might not support
146 the same auth methods (e.g. OpenID) being used by the wiki itself.
147
148 Another approach would be for ikiwiki's own rcs plugin to generate a CGI wrapper
149 that invokes the repository browser CGI (which itself would _not_ be made
150 executable via `http` request). The `historyurl` and `diffurl` would then refer
151 to this wrapper. (In fact, they would not have to be specified in the config file,
152 as the plugin would know where it generated them. Instead, what would need to be
153 specified would be the filesystem path for the rcs browser being wrapped). The
154 wrapper could dissect the request parameters, identify the pages being accessed,
155 and subject them to the same accessibility tests used for the wiki. The rcs browser
156 itself needs to be configured to use the wrapper URL in all its generated links,
157
158 This might not be very hard to do with `gitweb` as it is already implemented in Perl.
159 The wrapper could probably import it and use its already-supplied routines to parse
160 the request into the affected file names, and probably complete the whole request
161 without a second `exec`. Other rcs backends might or might not be as easy.
162
163 ### Search
164
165 If [[plugins/search]] is enabled, private content is indexed and
166 searchable to the public.
167
168 ### Information leaks allowed by edit access
169
170 > Have you considered all the ways that anyone with edit access to the
171 > public wiki could expose information from the public wiki? For example,
172 > you could inline all the private pages into a public page. --[[Joey]]
173
174 Many ikiwiki features could give information exposure opportunities to someone
175 with edit access. The list here is surely incomplete, and would take a purposeful
176 review of the code and plugins (including third-party plugins) to complete.
177
178 * Directives that can inline information from other pages
179     * [[ikiwiki/directive/inline]] *the most obvious one*
180     * [[ikiwiki/directive/map]]
181     * [[ikiwiki/directive/brokenlinks]] ?
182     * [[ikiwiki/directive/orphans]] ?
183     * [[ikiwiki/directive/linkmap]] ?
184     * _others_?
185 * Not to forget `contrib` plugins
186     * [[plugins/contrib/report]] ?
187     * _others_?