Last modified: 2011-09-06 19:31:41 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T32330, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 30330 - geoiplookup returns bad data over HTTPS
geoiplookup returns bad data over HTTPS
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Ryan Lane
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-11 18:36 UTC by Kudu
Modified: 2011-09-06 19:31 UTC (History)
4 users (show)

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


Attachments

Description Kudu 2011-08-11 18:36:04 UTC
When going to http://geoiplookup.wikimedia.org/, the utility returns correct data. However, when accessing https://geoiplookup.wikimedia.org/, it returns something like this, which isn't correct for my IP (in fact, it's totally different):
  Geo = {"city":"San Francisco","country":"US","lat":"37.769699","lon":"-122.393303","IP":"208.80.152.21","netmask":"22"}
Comment 1 Casey Brown 2011-08-11 19:49:19 UTC
I can reproduce this issue. It looks like the HTTPS one is pulling something related to the office, and not the person viewing it.
Comment 2 Ryan Lane 2011-08-11 20:04:32 UTC
Yes. This is known. Since HTTPS is set up as an SSL termination cluster the varnish servers for geoiplookup see the IP address of the SSL cluster, and not that of the client. To fix this I've patched the geoiplookup code to use the X-Forwarded-For header if the request is coming from one of the SSL cluster nodes.

One of the four varnish nodes in pmtpa is running this code, and therefore returns the correct data. I plan on pushing the change out to other nodes when I get back from Israel.

For more information about how things work, see:

http://wikitech.wikimedia.org/view/Https
Comment 3 Roan Kattouw 2011-08-12 09:40:49 UTC
(In reply to comment #2)
> Yes. This is known. Since HTTPS is set up as an SSL termination cluster the
> varnish servers for geoiplookup see the IP address of the SSL cluster, and not
> that of the client.
208.80.152.21 reverse-DNSes to yvon.wikimedia.org, which is a box in Tampa, right? Then it's a bit strange to me that geoip returns "San Francisco, CA" and a set of coordinates in Mission Bay (an area in SF). Is the geoip database (and possibly other DBs as well) misinformed as to the location of our datacenter and do they think that because we own the IP range, and we're in SF, the IP range is in SF?

(Not that this matters terribly, of course, it just jumped out at me.)
Comment 4 Mark A. Hershberger 2011-08-12 20:32:57 UTC
bump for Ryan to deploy now that he is back.
Comment 5 Ryan Lane 2011-08-15 18:22:12 UTC
This should now be fixed. Try it out and let me know.
Comment 6 Casey Brown 2011-08-15 18:30:22 UTC
Working for me. Thanks, Ryan!
Comment 7 Roan Kattouw 2011-09-04 14:24:00 UTC
This is still broken for traffic going through esams:

http://geoiplookup.wikimedia.org/ :
Geo = {"city":"Assen","country":"NL","lat":"53.000000","lon":"6.550000","IP":"CENSORED","netmask":"CENSORED"}

https://geoiplookup.wikimedia.org/ :
Geo = {"city":"(null)","country":"NL","lat":"52.500000","lon":"5.750000","IP":"91.198.174.122","netmask":"24"}

IP resolves to maerlant.esams.wikimedia.org , which is not documented on wikitech but according to the server admin log seems to be the IPv6-v4 proxy in esams.
Comment 8 Roan Kattouw 2011-09-06 19:31:41 UTC
Ryan fixed this.

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


Navigation
Links