Write nginx-mediawiki

1 files changed, 71 insertions, 0 deletions

diff --git a/public/nginx-mediawiki.md b/public/nginx-mediawiki.md
new file mode 100644
index 0000000..92d2d39
--- /dev/null
+++ b/public/nginx-mediawiki.md
@@ -0,0 +1,71 @@
+An Nginx configuration for MediaWiki
+====================================
+---
+date: "2015-05-19"
+---
+
+There are [several][0] [example][1] [Nginx][2] [configurations][3]
+[for][4] [MediaWiki][5] floating around the web.  Many of them don't
+block the user from accessing things like `/serialized/`.  Many of
+them also [don't correctly handle][faq] a wiki page named `FAQ`, 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!
+
+[0]: http://wiki.nginx.org/MediaWiki
+[1]: https://wiki.archlinux.org/index.php/MediaWiki#Nginx
+[2]: https://www.mediawiki.org/wiki/Manual:Short_URL/wiki/Page_title_--_nginx_rewrite--root_access
+[3]: https://www.mediawiki.org/wiki/Manual:Short_URL/Page_title_-_nginx,_Root_Access,_PHP_as_a_CGI_module
+[4]: http://wiki.nginx.org/RHEL_5.4_%2B_Nginx_%2B_Mediawiki
+[5]: http://stackoverflow.com/questions/11080666/mediawiki-on-nginx
+[faq]: https://labs.parabola.nu/issues/725
+
+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 `index.php`.
+
+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.
+
+	root /path/to/your/mediawiki; # obviously, change this line
+
+	index index.php;
+	location /                     { try_files /var/empty @rewrite; }
+	location /images/              { try_files $uri $uri/ @rewrite; }
+	location /skins/               { try_files $uri $uri/ @rewrite; }
+	location /api.php              { try_files /var/empty @php; }
+	location /api.php5             { try_files /var/empty @php; }
+	location /img_auth.php         { try_files /var/empty @php; }
+	location /img_auth.php5        { try_files /var/empty @php; }
+	location /index.php            { try_files /var/empty @php; }
+	location /index.php5           { try_files /var/empty @php; }
+	location /load.php             { try_files /var/empty @php; }
+	location /load.php5            { try_files /var/empty @php; }
+	location /opensearch_desc.php  { try_files /var/empty @php; }
+	location /opensearch_desc.php5 { try_files /var/empty @php; }
+	location /profileinfo.php      { try_files /var/empty @php; }
+	location /thumb.php            { try_files /var/empty @php; }
+	location /thumb.php5           { try_files /var/empty @php; }
+	location /thumb_handler.php    { try_files /var/empty @php; }
+	location /thumb_handler.php5   { try_files /var/empty @php; }
+	location /wiki.phtml           { try_files /var/empty @php; }
+
+	location @rewrite {
+		rewrite ^/(.*)$ /index.php?title=$1&$args;
+	}
+
+	location @php {
+		# obviously, change this according to your PHP setup
+		include fastcgi.conf;
+		fastcgi_pass unix:/run/php-fpm/wiki.sock;
+	}
+
+We are now using this configuration on
+[ParabolaWiki](https://wiki.parabola.nu/), but with an alias for
+`location = /favicon.ico` to the correct file in the skin, and with
+FastCGI caching for PHP.
+
+The only thing I don't like about this is the `try_files /var/emtpy`
+bits--surely there is a better way to have it go to one of the `@`
+location blocks, but I couldn't figure it out.