diff options
Diffstat (limited to 'public/nginx-mediawiki.html')
| -rw-r--r-- | public/nginx-mediawiki.html | 37 |
1 files changed, 31 insertions, 6 deletions
diff --git a/public/nginx-mediawiki.html b/public/nginx-mediawiki.html index f18ff22..1b7b2b6 100644 --- a/public/nginx-mediawiki.html +++ b/public/nginx-mediawiki.html @@ -9,10 +9,29 @@ <body> <header><a href="/">Luke Shumaker</a> » <a href=/blog>blog</a> » nginx-mediawiki</header> <article> -<h1 id="an-nginx-configuration-for-mediawiki">An Nginx configuration for MediaWiki</h1> -<p>There are <a href="http://wiki.nginx.org/MediaWiki">several</a> <a href="https://wiki.archlinux.org/index.php/MediaWiki#Nginx">example</a> <a href="https://www.mediawiki.org/wiki/Manual:Short_URL/wiki/Page_title_--_nginx_rewrite--root_access">Nginx</a> <a href="https://www.mediawiki.org/wiki/Manual:Short_URL/Page_title_-_nginx,_Root_Access,_PHP_as_a_CGI_module">configurations</a> <a href="http://wiki.nginx.org/RHEL_5.4_%2B_Nginx_%2B_Mediawiki">for</a> <a href="http://stackoverflow.com/questions/11080666/mediawiki-on-nginx">MediaWiki</a> floating around the web. Many of them don’t block the user from accessing things like <code>/serialized/</code>. Many of them also <a href="https://labs.parabola.nu/issues/725">don’t correctly handle</a> a wiki page named <code>FAQ</code>, since that is a name of a file in the MediaWiki root! In fact, the configuration used on the official Nginx Wiki has both of those issues!</p> -<p>This is because most of the configurations floating around basically try to pass all requests through, and blacklist certain requests, either denying them, or passing them through to <code>index.php</code>.</p> -<p>It’s my view that blacklisting is inferior to whitelisting in situations like this. So, I developed the following configuration that instead works by whitelisting certain paths.</p> +<h1 id="an-nginx-configuration-for-mediawiki">An Nginx configuration for +MediaWiki</h1> +<p>There are <a href="http://wiki.nginx.org/MediaWiki">several</a> <a +href="https://wiki.archlinux.org/index.php/MediaWiki#Nginx">example</a> +<a +href="https://www.mediawiki.org/wiki/Manual:Short_URL/wiki/Page_title_--_nginx_rewrite--root_access">Nginx</a> +<a +href="https://www.mediawiki.org/wiki/Manual:Short_URL/Page_title_-_nginx,_Root_Access,_PHP_as_a_CGI_module">configurations</a> +<a href="http://wiki.nginx.org/RHEL_5.4_%2B_Nginx_%2B_Mediawiki">for</a> +<a +href="http://stackoverflow.com/questions/11080666/mediawiki-on-nginx">MediaWiki</a> +floating around the web. Many of them don’t block the user from +accessing things like <code>/serialized/</code>. Many of them also <a +href="https://labs.parabola.nu/issues/725">don’t correctly handle</a> a +wiki page named <code>FAQ</code>, since that is a name of a file in the +MediaWiki root! In fact, the configuration used on the official Nginx +Wiki has both of those issues!</p> +<p>This is because most of the configurations floating around basically +try to pass all requests through, and blacklist certain requests, either +denying them, or passing them through to <code>index.php</code>.</p> +<p>It’s my view that blacklisting is inferior to whitelisting in +situations like this. So, I developed the following configuration that +instead works by whitelisting certain paths.</p> <pre><code>root /path/to/your/mediawiki; # obviously, change this line index index.php; @@ -45,8 +64,14 @@ location @php { include fastcgi.conf; fastcgi_pass unix:/run/php-fpm/wiki.sock; }</code></pre> -<p>We are now using this configuration on <a href="https://wiki.parabola.nu/">ParabolaWiki</a>, but with an alias for <code>location = /favicon.ico</code> to the correct file in the skin, and with FastCGI caching for PHP.</p> -<p>The only thing I don’t like about this is the <code>try_files /var/emtpy</code> bits—surely there is a better way to have it go to one of the <code>@</code> location blocks, but I couldn’t figure it out.</p> +<p>We are now using this configuration on <a +href="https://wiki.parabola.nu/">ParabolaWiki</a>, but with an alias for +<code>location = /favicon.ico</code> to the correct file in the skin, +and with FastCGI caching for PHP.</p> +<p>The only thing I don’t like about this is the +<code>try_files /var/emtpy</code> bits—surely there is a better way to +have it go to one of the <code>@</code> location blocks, but I couldn’t +figure it out.</p> </article> <footer> |