Actually I also had to add a `RewriteCond %{REQUEST_FILENAME} ^/?images` to prevent /index.php from being broken.
My root .htaccess looks something like this now:
RewriteEngine on
# Protect against bug 28235 RewriteCond %{REQUEST_FILENAME} ^/?images RewriteCond %{QUERY_STRING} .[a-z0-9]{1,4}(#|?|$) [nocase] RewriteRule . - [forbidden]
# Thumbnail handler for image thumbnails RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(/?)images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ $1thumb.php?f=$2&width=$3 [L,QSA]
# Thumbnail handler for archived images RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(/?)images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ $1thumb.php?f=$2&width=$3&archived=1 [L,QSA]
# Handler for 404 pages RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^/?.*$ /index.php?title=Special:Error404 RewriteRule ^(/?)images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ $1thumb.php?f=$2&width=$3 [L,QSA]
I haven't figured out how to replicate that bug 28235 fix in Nginx though.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 11-04-19 09:28 AM, Daniel Friesen wrote:
Using the rewrite inside images/.htaccess appears to conflict with existing installations with a root .htaccess including the code for the thumbnail handler.
You won't notice it right away because most images will already have existing thumbnails generated, but at some random point when someone.
In fact, I ONLY found out things were broken on any of my wiki after I created a brand new wiki with similar config and found I got 404s instead of thumbnails.
My fix was to comment out the code in images/.htaccess and add it to my root .htaccess. Of course I'll need to do something else on another one of my wiki that uses a separate domain for serving uploads.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 11-04-14 12:47 AM, Tim Starling wrote:
Our patch for the Internet Explorer 6 XSS issue (bug 28235) released two days ago in 1.16.3 was insufficient to fix that bug. The original reporter, Masato Kinugawa, pointed out the flaw on bug 28507. So we are doing another release, which contains a second attempt at fixing the issue.
Apologies to everyone for the inconvenience. Big thanks go to Masato Kinugawa for helping to keep MediaWiki secure. Thanks also to Roan Kattouw who helped me test the patch this time around, so that we can hopefully avoid a repeat.
It is necessary to upgrade MediaWiki to avoid an XSS vulnerability for Internet Explorer clients, version 6 and earlier. Also, if you used the Apache configuration I suggested in the previous release announcement, you should update it to:
RewriteEngine On RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase] RewriteRule . - [forbidden]We missed the fact that there can be more than one question mark in a URL. In certain circumstances, IE 6 will use a file extension immediately before a question mark character, regardless of how many question marks precede it. For example, with the URL:
http://example.com/a?b?c.html?d?e
IE 6 will see the file extension as ".html".
Download: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz
Patch to previous version (1.16.3): http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz
GPG signatures: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz.sig http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz.sig
Public keys: https://secure.wikimedia.org/keys.html