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