[Mediawiki-l] Slowness Thread Continued

[N. M. Buzdor]

>> You can comment out the redirect part in RawPage.php, about 2/3 down.
> DO NOT COMMENT THAT OUT! It's a workaround for an IE security flaw, for
> which we made a security fix release in late September.

Brion Vibber--

I believe you, though I'm not sure how that could be a real security threat
since it's only data that the client already has anyway.  However, just
because I don't understand doesn't mean I will decline your good advice.

> The workaround is to require that a 'raw' access be made from a
> canonical script URL, ... I did this
> with a redirect (instead of simply a 403 rejection) to preserve
> existing links.

Perhaps I could modify the testing lines of my copy of the script to ignore,
specifically, the cmw/ addition.  This should not prevent the security check
from keeping it's promise to ward off invalid requests.

> No, that's an URL rewrite which passes the new URL (eg /cmw/index.php)
> internally to the final request.

Ah, my experience was with IIS, but this is installed under Apache.  So I
misinterpreted the role of .htaccess in that capacity.

> If you want to map the physical path directly, normally you'd use a
> DocumentRoot directive in the virtual host configuration.

I'm afraid that with my hosting provider (as with 99% of potential hosting
providers for MediaWiki's installation base) do not give httpd.conf access,
they merely allow .htaccess files to be uploaded.  Do you have a suggestion
(here and for posterity) of an .htaccess change that will satisfy the strict
requirements of your security hole patch while allowing administrators to
use subdomains?  Neither DocumentRoot nor Alias seems to be quite the right
thing for mere .htaccess useage.

> Unfortunately this breaks wikis where edit/diff etc urls are supposed to
> be short and tidy. There the browser gets stuck in an endless
> redirection loop. It's not too hard to fix this though, will change it
> in the next days.

That sounds like the penultimate solution.  Will you issue it as a straightf
orward "change this line to that" patch, or should I grab a diff/merge tool
to install a whole new package when you issue 1.3.9a?

Meanwhile, I will contact my host provider and the user group there to see
if there's an .htaccess solution so that we don't have to make unneccesary
changes to the codebase.

Thanks for your ongoing attention and problem solving skills,
--N. Buzdor