wishlist: ask about using ikiwiki as ML

[ikiwiki.git] / doc / todo / Zoned_ikiwiki.mdwn

diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index f7f99b2ac489af7fb887d0ed5f0993e42ac64d4d..6b562215aa81221b87928c0fc2ab3cf1193e93a9 100644 (file)
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -46,10 +46,11 @@ 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*
-yet at the cost of maintaining two different user/pass logbase (native ikiwiki signin)
-* Clunky if ikiwiki is using an authentication method not natively supported
-    in the `http` server (e.g., OpenID).
+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
 
@@ -66,6 +67,12 @@ 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`.
 
+The plugin emits response headers intended to discourage non-private caches
+from retaining the retrieved content. (They are already supposed to avoid
+caching any response to a request with an `Authorization` header, but this
+plugin can be used with any ikiwiki-supported auth method, not all of which
+require that header.)
+
 A plugin like [[plugins/contrib/pagespec_alias]] can be very useful for
 defining a group of authorized users:
 
@@ -90,7 +97,21 @@ 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.
+per access. It would also be simpler than [[plugins/contrib/signinview]] by
+leaving it as the `http` server's responsibility to generate the proper headers
+and serve the content.
+
+Caching proxies are already supposed to avoid caching any response to a request
+that included an `Authorization` header. For some ikiwiki-supported auth methods,
+that header might not be needed in the request, and care may be needed to configure
+the server to emit other necessary response headers to discourage caching of
+content from a private zone.
+
+*Drawbacks:* Not yet implemented, someone would have to do it.
+It's not clear [[what code changes fastcgi|todo/fastcgi or modperl installation instructions]]
+would require in ikiwiki. An Authorizer seems like a good place to start because of its
+limited, simple functionality--but as it could make use of any ikiwiki-supported auth method,
+evaluate `PageSpec`s, and the like, it could still run a non-trivial amount of the code.
 
 ## Obstacles
 
@@ -233,3 +254,10 @@ review of the code and plugins (including third-party plugins) to complete.
 * Not to forget `contrib` plugins
     * [[plugins/contrib/report]] ?
     * _others_?
+
+Note that, _with_ the right controls on who can edit the pages and insert
+the directives, the fact that a public page can inline stuff from private
+pages can be very useful. Public pages can be created that are populated
+by selected content that's maintained on the private side. The [[ikiwiki/directive/if]]
+directive can be used in the private content to control what parts can be
+inlined into public pages. All of this is in ikiwiki today.