Hi Siddharth,
thank you for raising the concern. This is an issue that we have been
discussing, but I only realized today that there is probably an actual bug
contributing to the frustration.
Am 14.03.26 um 19:25 schrieb Siddharth VP:
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.
Our thinking was that the limits for well-behaved anonymous clients (i.e. ones
sending a good User-Agent) should be high enough to allow authentication without
problems. However, there seems to be a bug that prevents that from working
correctly for requests with expired tokens (T420106
<https://phabricator.wikimedia.org/T420106>). The bug would cause all clients
sharing an IP address to share a single counter and a low limit, which could be
a problem at a hackathon. Sorry about that.
That aside, we are now planning to exempt authentication endpoints entirely
(T419130 <https://phabricator.wikimedia.org/T419130>). I expect both fixes to be
deployed next week.
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-Agentheader.
I could be wrong, but if I recall correctly, the browser based OAuth flow is
implemented using Special pages, so it wouldn't be affected by API limits at all.
--
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/
