X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/fea2ec0926452ef3a8753791057bcabe8d212830..bc509a3119ee5c3704ad47e920bbba28f0b052f8:/doc/todo/Zoned_ikiwiki.mdwn

diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index f8c80837c..d618aec3c 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -5,13 +5,93 @@
 ## The idea
 
 The idea behind this would be to have one ikiwiki behave as a dynamic private wiki in a specified area
-and a more static publiczone wiki. Actually private wiki page can be addressed via a *pagespec*. 
+and a more static publiczone wiki.
 
-What is ready /can be done:
+## Use cases
 
-* We already can more or less do this for example with [[httpauth|/plugins/httpauth/]], *.htaccess* files and a proper *httpauth_pagespec*
-yet at the cost of maintaining two different user/pass logbase (native ikiwiki signin)
-* Furthermore we can [[lockedit|plugins/lockedit/]] some pagespecs, ie in the public zone.
+This can be more or less difficult depending on the use case.
+
+### Purely static public zone with a single, controlled-access inward zone
+
+For this case, only a known set of people are authorized to see the inward zone
+or edit anything. Everybody else sees only the public zone. This use case is mostly
+easy to handle now, as long as access to things like the `recentchanges` page and
+repository browser are not granted for the public zone. In particular, the features
+that allow information exposure via edit access are not of concern in this case.
+
+### Static public zone, more than one controlled inward zone
+
+In this case, the known, controlled set of people with special access are divided
+into groups with access to different (or overlapping) zones. The public still sees only a static zone.
+
+Here, some of the harder issues, like information disclosure via edit access, do apply,
+but only to members of the known, controlled groups. How much of a problem that is
+depends on _how sensitive_ the information is that each group might reveal from another
+zone. The rcs logs will show when a page has been edited to contain an [[ikiwiki/directive/inline]]
+directive or other trick to reveal information, so if it is enough to treat the trusted users' conduct
+as a management issue ("don't do that, please") then the risks can be acceptable in this case.
+
+### Public zone allows contribution/editing by external users
+
+This case is the most difficult to cover at present, and probably shouldn't be attempted
+without solutions to most or all of the **obstacles** identified here. 
+
+## Implementation techniques
+
+### Edit control by user and pagespec: lockedit
+
+This works today, using the [[plugins/lockedit]] plugin. Because the `user` predicate
+can be part of a [[ikiwiki/PageSpec]], this is all we need to flexibly control edit access
+using any authentication method `ikiwiki` supports.
+
+### View control in the `http` server
+
+We already can more or less do this for example with [[httpauth|/plugins/httpauth/]], `.htaccess` files and a proper `httpauth_pagespec`.
+
+_Drawbacks:_ might be fiddly to configure and require maintaining two different user/pass logbases (native ikiwiki
+signin), or impractical if ikiwiki is using an authentication method not natively supported
+in the `http` server (e.g., OpenID).
+
+### View control in ikiwiki CGI
+
+By requiring access to private zones to go through an ikiwiki CGI wrapper,
+any ikiwiki-supported authentication method can be used, and the accessible
+pages can be specified using the `user` predicate with [[ikiwiki/PageSpec]]s,
+just as with the [[plugins/lockedit]] plugin.
+
+The [[plugins/contrib/signinview]] plugin implements this idea, using very
+simple configuration that is possible even in shared-hosting environments
+without complete access to the `http` server configuration, as long as
+`.htaccess` files or their equivalent can be created. The top directory of
+a private zone needs only a `.htaccess` file with `Deny from All` or
+`Require all denied` (or other equivalent directive for the `http` server
+in use), and a `403` error handler of `{$cgiurl}?do=view`.
+
+A plugin like [[plugins/contrib/pagespec_alias]] can be very useful for
+defining a group of authorized users:
+
+    us: user(alice) or user(bob) or user(clotaldo)
+
+so that zone access can be a simple [[ikiwiki/PageSpec]]:
+
+    us() and ours/*
+
+*Drawbacks:* The private zones no longer reap all the benefits of a static
+wiki generator, as a (fairly heavy) ikiwiki CGI wrapper must be started for
+each access. (On the other hand, all it needs to do after confirming authorization
+is basically `cat` the statically-generated page with appropriate response headers,
+keeping the code simple and easy to audit.)
+
+This can be adequate for a case where the static, public zone could receive a lot
+of traffic, with the private zone(s) accessed only by a known small group of people.
+
+### View control with a FastCGI Authorizer
+
+A plugin implementing a [FastCGI](http://www.fastcgi.com/)
+[Authorizer](http://www.fastcgi.com/drupal/node/6?q=node/22#S6.3) could provide
+the same benefits as [[plugins/contrib/signinview]] (any ikiwiki-supported auth
+method, simple zone definition with [[ikiwiki/PageSpec]]s) with less overhead
+per access.
 
 ## Obstacles
 
@@ -129,6 +209,11 @@ The wrapper could probably import it and use its already-supplied routines to pa
 the request into the affected file names, and probably complete the whole request
 without a second `exec`. Other rcs backends might or might not be as easy.
 
+### Search
+
+If [[plugins/search]] is enabled, private content is indexed and
+searchable to the public.
+
 ### Information leaks allowed by edit access
 
 > Have you considered all the ways that anyone with edit access to the