Re: New global API rate limits deployed for anonymous requests
Travis Briggs via Wikitech-l <[email protected]> Mon, 16 Mar 2026 04:07:24 -0700
| Newsgroups | gmane.science.linguistics.wikipedia.technical |
|---|---|
| Message-ID | <CAMPYpA7cojgTxbFBGTNNQt5WAp=bN9aNVL21N0pGU0Z7qY1wJQ@mail.gmail.com> |
Great idea, I think Referer is completely reasonable as a rate limiting signal, because it is no worse than User-Agent from a spoofing/abuse perspective. -Travis On Mon, Mar 16, 2026 at 3:45 AM Addshore via Wikitech-l < [email protected]> wrote: > > Maybe one solution would be to move unauthenticated requests to the > > backend (the PHP API layer) as well because then it's clear that > > they're coming from toolforge.org? But that would unfortunately > > require a lot of refactoring of this app, and many older ones which i > > doubt still have maintainers. > > > Also, you would basically be running an open proxy now, that could be > abused by scrapers to access the API. If the kind of access is > restrictive enough this could be a viable work-around, but you'd have to > keep an eye on it to spot abuse. > > So I tried this (in a way) for wikicrowd at the hackathon, with > authentication still for the user to this (open proxy) to both 1 perform > the requests fro WMCS but then also more easily authenticate them. > However due to the number of requests tihs essentially just overwhelms my > tool infrastructure. > I have since undone this. > > I was then also directed toward `Api-User-Agent` and the hcakathon, and > implemented this for requests, but still ran into 429 issues. > > I'll be trying to take a fesh look at this at some point to try and > reoslve some issues. > > wikicrowd essentially makes requests to: > - Thumbnails such as this at 960px resolution > https://upload.wikimedia.org/wikipedia/commons/thumb/6/6c/Lake_LA-4-200_Buccaneer_AN1895272.jpg/960px-Lake_LA-4-200_Buccaneer_AN1895272.jpg > - Wikidata rest API for label lookup, such as > https://www.wikidata.org/w/rest.php/wikibase/v1/entities/items/Q7428391/labels_with_language_fallback/en > - Entity retrieval such as > https://commons.wikimedia.org/w/api.php?action=wbgetentities&format=json&ids=M75693953&props=claims&origin=* > > As with depictor, for some parts of the tool these are all client side > unauthenticated requests currently, made by the users browser. > I need to read up on the docs for doig user authentication for these GET > requests. > > I can likely resolve some of my issues by changing some of these requests > for additional batching (Vs the current optimization which is for caching). > > I also wonder if things like > origin https://wikicrowd.toolforge.org > referer https://wikicrowd.toolforge.org/ > could be considered as part of this rate limiting approach? > > On Sun, 15 Mar 2026 at 10:08, Daniel Kinzler via Wikitech-l < > [email protected]> wrote: > >> >> Am 15.03.26 um 09:03 schrieb Siddharth VP: >> >> So, it would be great if we could treat requests to >> rest.php/oauth2/authorize as trusted even if they don't have a user agent. >> >> This should become a non-issue when that endpoint is exempted from rate >> limits. >> >> -- >> Daniel Kinzler >> Principal Software Engineer >> MediaWiki Engineering Group >> Wikimedia Foundation >> >> >> _______________________________________________ >> Wikitech-l mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ > > _______________________________________________ > Wikitech-l mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ _______________________________________________ Wikitech-l mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/