## Implementation techniques
-What is ready /can be done:
+### Edit control by user and pagespec: lockedit
-* 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 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`.
+
+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:
+
+ 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. 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
Note that not all of these issues will be problems for all **zoned ikiwiki use cases**.
+### Leakage of page existence by `do=goto`
+
+An unauthorized client can use a `do=goto` request to find out whether a
+page exists (will be forbidden to view it) or not (will be forbidden to create it).
+
+In [[plugins/contrib/signinview]] this is handled by hooking
+`cgi` first and checking for `goto` and a non-public page. If the requested page
+(existing or not) matches the `public_pages` PageSpec, it is handed off for the `goto`
+plugin to handle normally. Otherwise, the `do` parameter is changed to `signingoto`
+so the `goto` plugin's `cgi` hook will _not_ handle it, and the `sessioncgi` hook
+takes care of it when the user's identity is available.
+
### Backlinks
What is problematic is when you link a public page in a private page :
* 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.