Why is this being rolled out in such a way that it feel like this is something the WMF is trying to obfuscate? I have seen politicians give straighter answers. The limits should be clearly defined, communicated and posted. When sending emails an other communications post the information, not just a link. It’s frustrating when reading an announcement that the actual useful information isn’t there and instead I have to go find it via a link.
On Sat, Mar 14, 2026 at 3:21 PM Ariel Glenn WMF via Wikitech-l < [email protected]> wrote: > As the Wikitech rate limits page at > https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits says: "Specific > limits for each group are currently being finalized based on > experimentation and observation". It's going to take some time and some > fiddling to figure out good values that keep the scrapers away and let the > rest of us contribute without problems. I would recommend to attendees that > they set a good user agent and let's see how that works out. > > Ariel Glenn > MediaWiki Platform > Wikimedia Foundation > > On Sat, Mar 14, 2026 at 12:05 PM Travis Briggs via Wikitech-l < > [email protected]> wrote: > >> Hi, >> >> I'm currently, right now, at a Wikimedia themed hackathon that I'm >> running (https://wikigamejam.org/sf-2026). >> >> I see this: >> User-Agent only Unauthenticated requests that provide a User-Agent >> header that is compliant with the User-Agent policy >> <https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_User-Agent_Policy> >> . low >> I'm wondering if the definition of "low" is intentionally obfuscated for >> some security purpose? >> >> The people at our hackathon are very new to Wikimedia APIs and I just >> want to gut check if the limits will cause them problems. >> >> Thanks, >> -Travis >> >> On Sat, Mar 14, 2026 at 11:27 AM Siddharth VP via Wikitech-l < >> [email protected]> wrote: >> >>> It looks like the rate limiting is also being applied to requests to >>> /w/rest.php/oauth2/authorize. Is this intentional? The user naturally >>> won't be authenticated yet during OAuth authorization. As OAuth is >>> typically implemented by using a 302 redirect to send the user to >>> /authorize, apps don't have control over the user agent as that's set >>> by the browser, nor is it possible to make the browser set the >>> Api-User-Agent header. >>> >>> This was brought up in >>> https://github.com/wikimedia-gadgets/gadget-deploy/issues/7. >>> >>> On Sat, 14 Mar 2026 at 15:01, Daniel Kinzler via Wikitech-l < >>> [email protected]> wrote: >>> >>>> Hello Piotr, >>>> >>>> Tools like this should continue to work fine if they authenticate when >>>> making the API requests. We don't want to break community tools, but we >>>> can't distinguish them from commercial scrapers, which we want to rate >>>> limit. So the way to fix the tools is to make the user log in, or to run >>>> the tools on WMCS. >>>> >>>> The there are problems with making tools authenticate for making API >>>> calls, please let us know. >>>> >>>> HTH, >>>> Daniel >>>> >>>> Am 13.03.26 um 22:41 schrieb Piotr Gackowski via Wikitech-l: >>>> >>>> This change has more or less crashed my workflows related to Structured >>>> Data on Commons. >>>> >>>> Both Depictor and Wikicrowd have effectively stopped working for me. >>>> The “for me” part is important — I have been making more than 100k edits >>>> per month for the last three years. >>>> >>>> I have already reported the issues to the tool maintainers: >>>> https://github.com/hay/wiki-tools/issues/179 >>>> https://github.com/addshore/wikicrowd/issues/236 >>>> >>>> However, I want to highlight a broader problem. At Wikimania 2024 in >>>> Katowice, I gave a presentation about adding Structured Data to Commons >>>> [1]. During that talk, I recommended tools such as Depictor, Wikicrowd, >>>> AC/DC, and the SDC tool. Since then, every single tool I mentioned has >>>> become heavily limited by some form of rate limiting. >>>> >>>> As a result, I increasingly feel that my hands are tied with every new >>>> change introduced by WMF in this area. >>>> >>>> PMG >>>> [1] >>>> https://wikimania.wikimedia.org/wiki/2024:Program/What_tools_you_can_use_to_fill_Structure_Data_on_Commons_files >>>> . >>>> >>>> czw., 12 mar 2026 o 11:47 Daniel Kinzler via Wikitech-l < >>>> [email protected]> napisał(a): >>>> >>>>> Hi all! >>>>> >>>>> As previously announced >>>>> <https://lists.wikimedia.org/hyperkitty/list/[email protected]/thread/GBFZTN3A233IR6F4HEENCIUCVI2ZH6YB/>, >>>>> we have started rolling out new global API rate limits across our APIs to >>>>> help ensure fair and sustainable access >>>>> <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Content_Reuse> >>>>> to Wikimedia resources. >>>>> >>>>> We have just enabled the first set of limits, which apply to anonymous >>>>> requests from bots and unauthenticated requests from web browsers. See the >>>>> documentation on mediawiki.org <http://mediawiki.org> for more >>>>> information. This has now been updated with actual limits for anonymous >>>>> requests and authenticated bot requests that do not come from WMCS. We are >>>>> still finalizing the initial limits for User-Agent only (e.g. >>>>> InstantCommons) and authenticated browser requests. >>>>> >>>>> As a next step, rate limits for logged in users will follow in early >>>>> April >>>>> <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Responsible_Reuse/WE5.1:_Developer_authentication_and_authorization#Timeline>. >>>>> The concrete limits will be communicated beforehand. Access for clients >>>>> running in WMCS and accounts that have a bot flag will not be affected by >>>>> this change. However, all developers are advised to familiarize themselves >>>>> with the new limits and follow the best practices outlined in the >>>>> documentation. >>>>> >>>>> If you see any unexpected issues that might be the result of the >>>>> limits rolled out today, we are actively monitoring this list, relevant >>>>> Talk pages and [email protected]. >>>>> >>>>> -- >>>>> 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/ >>>> >>>> >>>> -- >>>> 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/ > > _______________________________________________ > 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/
