Last modified: 2005-09-18 12:10:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 843 - Feature request: support for HTTP_X_FORWARDED_FOR header
Feature request: support for HTTP_X_FORWARDED_FOR header
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: 1590 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2004-11-08 19:09 UTC by Rob Hooft
Modified: 2005-09-18 12:10 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Rob Hooft 2004-11-08 19:09:48 UTC
Apparently some proxies do add a HTTP X-Forwarded-For header to the request. If
the wikimedia software would support such headers for known proxy servers, this
would allow more selective blocking of vandals using proxies.

- It would allow other users using the same proxy to keep working even while a
vandal is being blocked.
- It would make it impossible for a vandal to use proxy hopping

Obviously we can not blindly trust this header in just any request, so my
proposal would be to have a sysop command that marks an IP as a known proxy. If
a request comes from such a marked proxy, the contributor would be taken from
the IP address in the X-Forwarded-For header instead, and this address would be
used for access control instead of the proxy address itself.
Comment 1 Pedro Gimeno 2004-11-26 22:01:36 UTC
Please do. I'm forced by my ISP to be behind a transparent proxy and my real IP
address never matches the one displayed. If the proxy's address is banned, a
great amount of users connected via this ISP and others will be banned at the
same time. That's because the proxy belongs to the phone company who provides
the communication means.

Here's a piece of code to obtain the client's IP (from a comment in

function getIP() {

  if (getenv("HTTP_CLIENT_IP")) $ip = getenv("HTTP_CLIENT_IP");
  else if(getenv("HTTP_X_FORWARDED_FOR)) $ip = getenv("HTTP_X_FORWARDED_FOR");
  else if(getenv("REMOTE_ADDR")) $ip = getenv("REMOTE_ADDR");
  else $ip = "UNKNOWN";

  return $ip;

but watch out for commas in the HTTP_X_FORWARDED_FOR result. There's some code
in the mentioned address which explodes the string and returns an array.
I'm not an HTTP_X_FORWARDED_FOR expert so I don't know if the IP address to look
is the first or the last one. The comments there may help.

Comment 2 River Tarnell 2004-11-26 22:18:32 UTC
We already support extracting IPs from proxy headers for Squid support (see
$wgSquidServers and Setup.php).  The only thing required to implement this would
therefore be to find a list of ISP proxy servers and add them to
$wgSquidServers--so it's mainly a policy issue rather than an implementation
issue (i.e. do we want to do this or not).

I'm closing this as RESOLVED INVALID for this reason; if people either want it
done on Wikimedia sites or a feature to allow $wgSquidServers to be updated by
sysop, it's probably best to open a new bug.
Comment 3 Zigger 2005-09-18 12:09:19 UTC
*** Bug 1590 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.