Page MenuHomePhabricator

Proxy scanning triggered with every edit, resulting in server overload
Closed, DeclinedPublic

Description

Author: temlakos

Description:
We have noticed a show-stopping problem with unwanted automatic proxy checking being done without our setting the involved variable ($wgBlockOpenProxies). We are trying to establish a new server that uses cPanel and stores the wiki in a directory like this:

/home/user_name/public_html

With any edit that anyone makes, proxy_check.php goes wild and the entire server is overloaded and can't do anything. This problem first came up rather suddenly when we upgraded to MediaWiki release 1.12. We were told that we could no longer host our wiki on a semi-dedicated server, because other accounts were suffering. So we got a fully dedicated server, but with a different control-panel application (Parallels Plesk) and directory structure:

/var/www/vhosts/domain.name/httpdocs

The problem: we wanted to upgrade our hardware, and also to move back from Plesk to cPanel, after we had issues with administrative e-mail not getting out to new account registrants. The old server doesn't do this unwanted proxy checking, but the new server does--every time. We tried upgrading to MW release 1.16 and disabling all extensions. No joy.

How can we make sure that proxy checking never occurs? Why should MediaWiki not "play nice" with cPanel? Does MW have some script that says that it will do proxy checking automatically if it is on a

/home/user_name/public_html

type directory structure?


Version: 1.16.x
Severity: blocker
OS: Linux
Platform: PC

Details

Reference
bz24717

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 21 2014, 11:04 PM
bzimport set Reference to bz24717.
bzimport added a subscriber: Unknown Object (MLST).

Most likely, $wgBlockOpenProxies was set to true, but you thought it wasn't because you were reading the wrong LocalSettings.php file. Since you probably won't believe me about that, replacing proxy_tools.php with an empty (zero-byte) file would be another possible solution. Or you could delete the wfProxyCheck() call in EditPage.php.

temlakos wrote:

(In reply to comment #1)

Most likely, $wgBlockOpenProxies was set to true, but you thought it wasn't
because you were reading the wrong LocalSettings.php file. Since you probably
won't believe me about that, replacing proxy_tools.php with an empty
(zero-byte) file would be another possible solution. Or you could delete the
wfProxyCheck() call in EditPage.php.

I thought that might be it. It's just that my LocalSettings.php says nothing about $wgBlockOpenProxies = true or anything like that.

I might have a workaround. Do you recommend removing $wgProxyKey and/or $wgSecretKey?

How if I explicitly set $wgBlockOpenProxies = false?

I'll remember that: EditPage.php. Comment out the proxy-check call...yes, I'll do that.

On our wiki, we do not permit anonymous editing. Everyone who wants to edit, has to have a password-protected account with us. I see no need to worry about proxies, or about spoofing. I don't care if they come in via a proxy--so long as they authenticate themselves with us.

(In reply to comment #2)

How if I explicitly set $wgBlockOpenProxies = false?

Set it in your localsettings file, It will override whatever the default is, even if it is false.

Cannot replicate on trunk => WFM

aaron.schulz wrote:

content hidden as private in Bugzilla