<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>signinview (third party plugin)</title> <meta name="viewport" content="width=device-width, initial-scale=1" /> <link rel="stylesheet" href="../../style.css" type="text/css" /> <link rel="stylesheet" href="../../local.css" type="text/css" /> </head> <body> <div class="page"> <div class="pageheader"> <div class="header"> <span> <span class="parentlinks"> <a href="../../index.html">ikiwiki</a>/ <a href="../../plugins.html">plugins</a>/ <a href="../contrib.html">contrib</a>/ </span> <span class="title"> signinview (third party plugin) </span> </span> </div> </div> <div id="pagebody"> <div id="content" role="main"> <p><span class="infobox"> Plugin: signinview<br /> Author: <span class="createlink">jcflack</span><br /> Included in ikiwiki: no<br /> Enabled by default: no<br /> Included in <a href="../goodstuff.html">goodstuff</a>: no<br /> Currently enabled: no<br /> </span></p> <p>This plugin is one implementation approach to a <span class="createlink">zoned ikiwiki</span>. It is named like <a href="../signinedit.html">signinedit</a>, which requires users to sign in before editing pages. Similarly, this plugin requires users to sign in before <em>viewing</em> certain pages. Unlike <a href="../signinedit.html">signinedit</a>, which <em>only</em> checks that any user is signed in, this plugin is also similar to <a href="../lockedit.html">lockedit</a> in that it checks the user's identity and a <a href="../../ikiwiki/pagespec.html">PageSpec</a> to determine <em>which</em> pages may be viewed. It works with any auth methods ikiwiki supports, not only those the <code>http</code> server also understands.</p> <h2>How to configure</h2> <p>This plugin adds a new function, <code>do=view</code>, to ikiwiki's CGI wrapper. It is intended to be called by the <code>http</code> server as an <code>ErrorDocument</code> for the <code>403</code> (forbidden) error response.</p> <p>In order to be usable even in shared-hosting situations without full access to the <code>http</code> server configuration files, this plugin requires nothing more than <code>.htaccess</code> files, as long as the server is configured to honor <code>ErrorDocument</code> and <code>Deny</code> or <code>Require</code> directives in them.</p> <p>To divide the wiki into a public zone and one or more private zone(s), simply place <code>Require all denied</code> (Apache 2.4), <code>Deny from All</code> (Apache 2.2), or the equivalent directive for the server and version in use, on the topmost directory of any private zone, either in an <code>.htaccess</code> file, or in the server configuration file if possible. Any location outside of these will continue to be served as normal public static ikiwiki content.</p> <p>Then, if the <code>{$cgiurl}</code> is, for example, <code>/cgi-bin/ikiwiki.cgi</code>, add the directive</p> <pre><code>ErrorDocument 403 /cgi-bin/ikiwiki.cgi?do=view </code></pre> <p>at the private locations or any ancestor up to the documentroot itself, again either in a <code>.htaccess</code> file or in the server configuration file.</p> <p>That's it for the server configuration. The server will now punt every request for private content to the ikiwiki wrapper. Everything else about the authorization decision--what auth method to use, whether there is just one private zone or different zones for different users--is handled by ikiwiki using a <a href="../../ikiwiki/pagespec.html">PageSpec</a>.</p> <h3>viewable_pages config option</h3> <p>This option in <code>ikiwiki.setup</code> is a <a href="../../ikiwiki/pagespec.html">PageSpec</a> defining which pages can be viewed. Because one predicate that can be used in a <a href="../../ikiwiki/pagespec.html">PageSpec</a> is <code>user</code>, this is enough to define interesting access rules. For example:</p> <pre><code>viewable_pages: > ((user(astolfo) or user(basilio)) and team1/*) or ((user(clotaldo) or user(estrella)) and team2/*) </code></pre> <p>Note that this defines the conditions to <em>allow</em> viewing, which is opposite the sense of the <a href="../lockedit.html">lockedit</a> plugin, where you define the conditions to <em>deny</em> editing.</p> <p>If there are more than a few users in a group, or the specification for accessible pages is more complex, the <a href="./pagespec_alias.html">pagespec alias</a> plugin can be useful to factor things out. Note it currently must <span class="createlink">be patched</span> for this to work:</p> <pre><code>pagespec_aliases: team1: > user(astolfo) or user(basilio) team2: > user(clotaldo) or user(estrella) team1stuff: team1/* or common/* team2stuff: team2/* or common/* viewable_pages: > (team1() and team1stuff()) or (team2() and team2stuff()) </code></pre> <h3>mime_types config option</h3> <p>Normally, when serving the static pages of an ordinary public site, the <code>http</code> server itself is responsible for identifying the <code>Content-Type</code> of each file. However, for any page that is served by this plugin instead of directly, the CGI specification makes it <a href="http://tools.ietf.org/html/rfc3875#section-6.3.1">plugin's job</a>, not the server's, to identify the <code>Content-Type</code>.</p> <p>In the current version, this plugin does that in a dead-simple way. For any page that ikiwiki htmlized (that is, for which the <code>pagetype</code> <a href="../write.html">plugin API function</a> returns a value), the type <code>text/html</code> is assigned. For anything else, a simple collection of content types and <code>PageSpec</code>s must be configured in the <code>ikiwiki.setup</code> file:</p> <pre><code>mime_types: image/png: '*.png' application/pdf: '*.pdf' text/css: '*.css' </code></pre> <p>Anything without a matching rule gets served as <code>application/octet-stream</code>, which is probably not what you want, but a clear sign of what rule needs to be added.</p> <h2>Other considerations</h2> <h3>Leakage of non-content files</h3> <p>Any CGI code that does what this plugin does, and can serve requested files under the document root, needs to be careful not to allow viewing of certain sensitive files that may also be found there, such as <code>.htaccess</code>, <code>.htpasswd</code>, etc. Instead of trying to think of all the possible files that should not be served, this plugin takes an absolutely strict approach: every requested file is looked up in the <code>%destsources</code> hash, containing all the files ikiwiki has generated or placed in the web root. Any file that <em>ikiwiki didn't put there</em>, this plugin <em>won't touch</em>. Otherwise, its page name is now known, and must satisfy the <code>viewable_pages</code> <code>PageSpec</code>.</p> <p>This policy is also what allows this plugin to work back through <code>%pagesources</code> to the original source name, needed for the content-type rules described above.</p> <h3>Cache control</h3> <p>The purpose of a non-public zone can be defeated if there are caching proxies or other non-private caches that might retain the content this plugin returns.</p> <p>Caching of the response is automatically forbidden by the HTTP specification <a href="http://tools.ietf.org/html/rfc7234#section-3.2">if there was an <code>Authorization</code> header in the request</a>. However, this plugin works with any auth method ikiwiki supports, not all of which require that header, so this plugin always emits response headers to explicitly forbid caching.</p> <p>Note that nothing precludes an evil caching agent that ignores the rules.</p> <h3>Other ways to handle <code>Content-Type</code></h3> <p>While it is simple enough to supply a <code>mime_types</code> map in <code>ikiwiki.setup</code>, it also duplicates logic that has already been done to death in other places. Another approach would be to use <code>File::MimeInfo::Magic</code>, which is already present if the <code>filecheck</code> plugin is in use.</p> <p>In a wiki <em>compiler</em>, it would be natural to do that content-type determination at compile time and save it in page state, so this plugin would simply output the stored type. On the other hand, saving the type for every (non-htmlized?) page would enlarge the state <code>Storable</code> that has to be loaded, and so might not be faster than typing the file on the fly.</p> <h2>Obtaining and installing</h2> <p>The <code>signinview</code> plugin is <a href="https://github.com/jcflack/ikiwiki/tree/plug-signinview">not in github yet</a> (horroars! vaporware!). What <em>is</em> in github at the moment is a preliminary patch I have <a href="https://github.com/joeyh/ikiwiki/pull/14">proposed</a>, giving plugins some control over the environment variables that a generated wrapper will preserve.</p> <p>Depending on the ultimate fate of that patch, I will adjust/rebase and then push the <code>signinview</code> branch itself.</p> </div> </div> <div id="footer" class="pagefooter" role="contentinfo"> <div id="pageinfo"> <div class="tags"> Tags: <a href="../type/special-purpose.html" rel="tag">type/special-purpose</a> </div> <div class="pagedate"> Last edited <span class="date">Tue Feb 26 23:01:54 2019</span> <!-- Created <span class="date">Tue Feb 26 23:01:54 2019</span> --> </div> </div> <!-- from ikiwiki --> </div> </div> </body> </html>