Hi there, I was wondering if you were planning on exposing some kind of rate-limiting option for the web proxies in horizon? I'm thinking this will effectively mean no more rate-limiting per remote address at the instance level. Every once in a while, our project gets hammered by script kiddies and our application service gets brought down. I've gone ahead and implemented rate limiting in nginx that has a very high limit set across all ip addresses that should basically work, but typically I would set the limits to be per-client-ip to the extent allowed by the practicalities of NAT. This is not a blocker in any way for us, and I'd rather make do with less user info wherever possible.
Thanks for making the development of tools and services for Wikimedia as painless as possible! On Wed, Apr 1, 2020 at 8:31 AM Arturo Borrero Gonzalez < [email protected]> wrote: > Hi there! > > If you use a CloudVPS web proxy, this email is for you. Toolforge > developers/users can ignore this email. > > We are introducing a change to eliminate the 'X-Forwarded-For' HTTP header > that > the CloudVPS web proxy adds when forwarding the HTTP request to your > instance. > This header contains the original IP address of the internet client that > sent > the request. This is private information that we would like to reduce in > our > environment [0]. > > You use the web proxy if you have a public web endpoint hosted in CloudVPS > under > the wmflabs.org domain. These are generally configured using Horizon in > the DNS > > Web Proxies section. > > Examples of web proxy names: > * accounts.wmflabs.org > * glampipe.wmflabs.org > * incubator.wmflabs.org > > Full list can be seen in the Openstack Browser tool [1]. > > We are ready to introduce this change [2], but wanted to give some heads > up for > projects that do require this information for whatever reason. We would > like to > hear from you in the next couple of weeks. Please contact us in the > phabricator > task [0] and include some rationale why you need the XFF header. > > This is the timeline this change will follow: > > * 2020-04-01: this email, start collecting list of things that require XFF > * 2020-04-07: start evaluating list of things that require XFF > * 2020-04-15: introduce the change, with proper case whitelisting > > When the change is introduced, in two weeks from now, proxy backends that > were > not whitelisted will stop receiving the XFF header. > > Please reach out for any questions or comments. > > regards. > > [0] https://phabricator.wikimedia.org/T135046 > [1] https://openstack-browser.toolforge.org/project/project-proxy > [2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/583098 > > -- > Arturo Borrero Gonzalez > SRE / Wikimedia Cloud Services > Wikimedia Foundation > > _______________________________________________ > Wikimedia Cloud Services announce mailing list > [email protected] (formerly > [email protected]) > https://lists.wikimedia.org/mailman/listinfo/cloud-announce > -- Jason
_______________________________________________ Wikimedia Cloud Services mailing list [email protected] (formerly [email protected]) https://lists.wikimedia.org/mailman/listinfo/cloud
