Re: why we can't allow anonymous edits

> 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.
>
>
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>


> Another thought (which I can't confirm for now) is, that this could also
> be a source of the session issues.
>
>
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.

- Ryan