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