W3C home > Mailing lists > Public > public-webplatform@w3.org > December 2012

Re: why we can't allow anonymous edits

From: frozenice <frozenice@frozenice.de>
Date: Tue, 18 Dec 2012 00:36:43 +0100
Message-ID: <50CFAC8B.5020904@frozenice.de>
To: public-webplatform@w3.org
-- Ryan's reply on XFF --

Yes, if we wanted to allow anon edits, we'd need to trust the XFF sent by fastly. This is also how Wikimedia's config works; see:

<http://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php>

-- Ryan's reply on the other thought --

Nope. The sessions are stored in memcache. No matter where the request comes from or which application server handles the request,
the session will be pulled from memcache, based on the auth cookie.


On 16.12.2012 04:16, frozenice wrote:
> Hi,
>
> as I stated in my other thread from just now (called "Some Charts about WPD Users"), there was a problem with IP addresses.
>
> When I asked the database for unique IPs in the recentchanges table (which contains about 26k rows),
> it replied with merely 18 distinct addresses. I wondered and then it struck me.
>
> Because we use a frontend cache (Fastly), user traffic looks like the following:
> User <--> Fastly <--> WPD
>
> This means MediaWiki doesn't see the user's IP, but the IP of a random cache from Fastly. This effectively means
> we can't block IPs in case of vandalism etc., because we would block a whole bunch of users.
>
> I don't know why I haven't thought of this earlier... I guess it's because I normally don't use frontend caches.
>
> Now, I don't know if Fastly sends X-Forwarded-For headers (it should) nor if MW can handle those. We would need
> a whitelist of Fastly IPs to be trusted with the XFF header and MW would then use that value as the real IP.
>
> Another thought (which I can't confirm for now) is, that this could also be a source of the session issues.
>
> - fro
>



Received on Monday, 17 December 2012 23:37:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:57:36 UTC