On Sun, 15 Mar 2026 at 01:49, Daniel Kinzler <[email protected]> wrote:
> Am 14.03.26 um 19:25 schrieb Siddharth VP: > > 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. > > 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. > The special page gets involved only after the call to the REST API passes. The full flow used by the gadget-deploy tool is: - The frontend calls the tool backend ( https://gadget-deploy.toolforge.org/initiate) - The backend sends a 302 redirect pointing to https://meta.wikimedia.org/w/rest.php/oauth2/authorize with the client id and redirect_uri params set. - Since the navigation is due to a 302 response, we can't set Api-User-Agent. - I suppose the frontend could just call it directly and then we'll be able to set the Api-User-Agent header, but that would mean exposing the client id to the frontend, which is doable but inconvenient (as it's easy for the server to read from a conf file, but in the UI it'll have to substituted into the UI code somehow). - meta.wikimedia.org/w/rest.php/oauth2/authorize redirects the user to meta.wikimedia.org/w/index.php?title=Special:OAuth/approve 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. Thanks, -- SD0001 (Siddharth VP)
_______________________________________________ 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/
