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 ### Edit control by user and pagespec: lockedit
  42
  43 This works today, using the [[plugins/lockedit]] plugin. Because the `user` predicate
  44 can be part of a [[ikiwiki/PageSpec]], this is all we need to flexibly control edit access
  45 using any authentication method `ikiwiki` supports.
  46
  47 ### View control in the `http` server
  48
  49 * We already can more or less do this for example with [[httpauth|/plugins/httpauth/]], *.htaccess* files and a proper *httpauth_pagespec*
  50 yet at the cost of maintaining two different user/pass logbase (native ikiwiki signin)
  51 * Clunky if ikiwiki is using an authentication method not natively supported
  52     in the `http` server (e.g., OpenID).
  53
  54 ### View control in ikiwiki CGI
  55
  56 By requiring access to private zones to go through an ikiwiki CGI wrapper,
  57 any ikiwiki-supported authentication method can be used, and the accessible
  58 pages can be specified using the `user` predicate with [[ikiwiki/PageSpec]]s,
  59 just as with the [[plugins/lockedit]] plugin.
  60
  61 The [[plugins/contrib/signinview]] plugin implements this idea, using very
  62 simple configuration that is possible even in shared-hosting environments
  63 without complete access to the `http` server configuration, as long as
  64 `.htaccess` files or their equivalent can be created. The top directory of
  65 a private zone needs only a `.htaccess` file with `Deny from All` or
  66 `Require all denied` (or other equivalent directive for the `http` server
  67 in use), and a `403` error handler of `{$cgiurl}?do=view`.
  68
  69 A plugin like [[plugins/contrib/pagespec_alias]] can be very useful for
  70 defining a group of authorized users:
  71
  72     us: user(alice) or user(bob) or user(clotaldo)
  73
  74 so that zone access can be a simple [[ikiwiki/PageSpec]]:
  75
  76     us() and ours/*
  77
  78 *Drawbacks:* The private zones no longer reap all the benefits of a static
  79 wiki generator, as a (fairly heavy) ikiwiki CGI wrapper must be started for
  80 each access. (On the other hand, all it needs to do after confirming authorization
  81 is basically `cat` the statically-generated page with appropriate response headers,
  82 keeping the code simple and easy to audit.)
  83
  84 This can be adequate for a case where the static, public zone could receive a lot
  85 of traffic, with the private zone(s) accessed only by a known small group of people.
  86
  87 ### View control with a FastCGI Authorizer
  88
  89 A plugin implementing a [FastCGI](http://www.fastcgi.com/)
  90 [Authorizer](http://www.fastcgi.com/drupal/node/6?q=node/22#S6.3) could provide
  91 the same benefits as [[plugins/contrib/signinview]] (any ikiwiki-supported auth
  92 method, simple zone definition with [[ikiwiki/PageSpec]]s) with less overhead
  93 per access.
  94
  95 ## Obstacles
  96
  97 A number of ikiwiki features aren't (yet) designed with zoning in mind,
  98 and it will take some effort both to identify them all, and to think out how they
  99 could be addressed. This section invites brainstorming of both kinds.
 100 This might eventually merit a separate page [[Zoned ikiwiki obstacles]]
 101 but I'll begin it here.
 102
 103 Note that not all of these issues will be problems for all **zoned ikiwiki use cases**.
 104
 105 ### Backlinks
 106
 107 What is problematic is when you link a public page in a private page :
 108 a backlink will be generated from the public page to the private page.
 109
 110 As noted in [[per_page_ACLs]] in the end users through backlink
 111 navigation will frequently hit HTTP/401 deterring browsing as well as for the admin at false-positive logwatching.
 112
 113 One can radically [[disable backlinks feature|todo/allow_disabling_backlinks]] but then no more neat backlink navigation that
 114 is really good to have in both area.
 115
 116 Another way of just preventing this backlink leak in that case would be sufficient via i.e a *privatebacklinks* config and
 117 a patch like this one [[!toggle id="backlinkpatch" text="(show)"]].
 118
 119 [[!toggleable id="backlinkpatch" text="""
 120 Comments are welcome.
 121
 122 [[mathdesc]]
 123
 124
 125 <pre>
 126 diff --git a/IkiWiki.pm b/IkiWiki.pm
 127 --- a/IkiWiki.pm
 128 +++ b/IkiWiki.pm
 129 @@ -294,6 +294,14 @@ sub getsetup () {
 130                 safe => 1,
 131                 rebuild => 1,
 132         },
 133 +       privatebacklinks => {
 134 +               type => "pagespec",
 135 +               example => "",
 136 +               description => "PageSpec controlling which backlinks are private (ie users/*)",
 137 +               link => "ikiwiki/PageSpec",
 138 +               safe => 1,
 139 +               rebuild => 1,
 140 +       },
 141         hardlink => {
 142                 type => "boolean",
 143                 default => 0,
 144 diff --git a/IkiWiki/Render.pm b/IkiWiki/Render.pm
 145 --- a/IkiWiki/Render.pm
 146 +++ b/IkiWiki/Render.pm
 147 @@ -52,7 +52,8 @@ sub backlinks ($) {
 148                         $p_trimmed=~s/^\Q$dir\E// &&
 149                         $page_trimmed=~s/^\Q$dir\E//;
 150
 151 -               push @links, { url => $href, page => pagetitle($p_trimmed) };
 152 +               push @links, { url => $href, page => pagetitle($p_trimmed) }
 153 +               unless defined $config{privatebacklinks} && length $config{privatebacklinks} && pagespec_match($p, $config{privatebacklinks}) && !pagespec_match($page, $config{privatebacklinks}) ;
 154         }
 155         return @links;
 156  }
 157
 158 </pre>
 159 """]]
 160
 161 In use cases where the main concern about backlinks is only the bad user experience when links are
 162 shown that lead to access denial when clicked, a workable
 163 solution could be to make the backlinks `div` invisible in `local.css`.
 164
 165 ### recentchanges page
 166
 167 An accessible `recentchanges` page can include links to changes to pages
 168 that should not be accessible. Even if the links cannot be followed, the
 169 existence of the pages and their edit history are leaked. If rcs integration
 170 is configured, those links on the `recentchanges` page can leak complete contents
 171 through the **rcs browser**.
 172
 173 It can be helpful to generate separate `recentchanges` pages for different zones.
 174 The [[plugins/recentchanges]] plugin already allows this--a `recentchanges` page
 175 can be created anywhere, just by using the `recentchanges` directive
 176 with the right [[ikiwiki/PageSpec]] for the zone it should cover--except that it cannot yet
 177 be configured to generate a different `recentchanges` link destination into pages
 178 in different zones. So, it would be helpful if its configuration could allow multiple
 179 `recentchangespage` values, paired with `PageSpec`s for the pages on which they
 180 should be used.
 181
 182 ### rcs browser
 183
 184 If the repository browser is accessible, potentially all content can be exposed.
 185 Even if links to the repository browser are not generated into public wiki pages,
 186 if a user can obtain or guess the repository browser URL and construct arbitrary
 187 requests, information can be revealed.
 188
 189 Solutions could involve authnz features of the revision control systems themselves
 190 and their associated repository browsers; for example, `svn` supposedly has such
 191 features, and recent versions of `viewvc` supposedly honor them. But such features
 192 may not be available for every rcs, and where they are available, they'll have to
 193 be configured separately and differently from ikiwiki itself. They might not support
 194 the same auth methods (e.g. OpenID) being used by the wiki itself.
 195
 196 Another approach would be for ikiwiki's own rcs plugin to generate a CGI wrapper
 197 that invokes the repository browser CGI (which itself would _not_ be made
 198 executable via `http` request). The `historyurl` and `diffurl` would then refer
 199 to this wrapper. (In fact, they would not have to be specified in the config file,
 200 as the plugin would know where it generated them. Instead, what would need to be
 201 specified would be the filesystem path for the rcs browser being wrapped). The
 202 wrapper could dissect the request parameters, identify the pages being accessed,
 203 and subject them to the same accessibility tests used for the wiki. The rcs browser
 204 itself needs to be configured to use the wrapper URL in all its generated links,
 205
 206 This might not be very hard to do with `gitweb` as it is already implemented in Perl.
 207 The wrapper could probably import it and use its already-supplied routines to parse
 208 the request into the affected file names, and probably complete the whole request
 209 without a second `exec`. Other rcs backends might or might not be as easy.
 210
 211 ### Search
 212
 213 If [[plugins/search]] is enabled, private content is indexed and
 214 searchable to the public.
 215
 216 ### Information leaks allowed by edit access
 217
 218 > Have you considered all the ways that anyone with edit access to the
 219 > public wiki could expose information from the public wiki? For example,
 220 > you could inline all the private pages into a public page. --[[Joey]]
 221
 222 Many ikiwiki features could give information exposure opportunities to someone
 223 with edit access. The list here is surely incomplete, and would take a purposeful
 224 review of the code and plugins (including third-party plugins) to complete.
 225
 226 * Directives that can inline information from other pages
 227     * [[ikiwiki/directive/inline]] *the most obvious one*
 228     * [[ikiwiki/directive/map]]
 229     * [[ikiwiki/directive/brokenlinks]] ?
 230     * [[ikiwiki/directive/orphans]] ?
 231     * [[ikiwiki/directive/linkmap]] ?
 232     * _others_?
 233 * Not to forget `contrib` plugins
 234     * [[plugins/contrib/report]] ?
 235     * _others_?