(Renamed to clarify that this is a request to our own API, not really "external" in the sense of external links.)

I'm tagging this as a security issue, because this issue is right now preventing any blocks from being imposed on at least the English Wiktionary, if not other wikis. Any sort of troublemakers could abuse this.

That was T404326 (https://wikimedia.statuspage.io/incidents/0b7z75f91m8q). I don't know the details, but I don't think this is something an attacker could cause. Thank you for being cautious, but I think this issue could be made public, which will make it easier to discuss (CC @sbassett).

I think the underlying DB error that caused the HTTP 502 has gone away, so yes, there probably isn't too much of a reason to keep this private anymore. I don't think it is very likely that an attacker could intentionally cause DB issues, but if they would, I doubt they would use it just to ensure that they can't get blocked.

The multiblock feature introduced in MW 1.44 brought with it a new "Manage blocks" page. This page seems to depend on an API query request in order to load correctly. An example XHR request sent by the UI for an IP looks like this:

https://en.wiktionary.org/w/api.php?action=query&format=json&list=blocks%7Cglobalallusers&bkusers=<IP>&bkprop=id%7Cuser%7Crange%7Ctimestamp%7Cexpiry%7Cby%7Creason%7Cflags&bkdir=older&agufrom=<IP>&aguto=<IP>&agulimit=1&aguprop=lockinfo

If this request fails to complete (e.g. because of a HTTP 502, like right now), the block interface never loads and it becomes impossible to block any users.

This particular request actually comes from an en.wiktionary.org gadget: https://en.wiktionary.org/wiki/MediaWiki:Gadget-BlockInfo.js#L-56

But it's true that the new Special:Block makes a bunch of API requests when it loads, and that it doesn't load if they fail (I tested locally by adding a dieWithError() call in ApiQuery::execute()).

It should probably have a no-JS interface (right now it just shows an error: "JavaScript is required to use the Special:Block interface."), and it could fall back to that interface if any of the required API requests fail.

I can't find the documentation for the decision just now, but it was an intentional choice (by Community-Tech) for the new multiblocks interface to be JS-only and not have a no-JS fallback. Mainly because it's a Vue app, and that there don't seem to be very many admins who work with JS turned off.

In T404315#11172422, @matmarex wrote:Thank you for being cautious, but I think this issue could be made public, which will make it easier to discuss (CC @sbassett).

Done.

We wanted to have a no-JS experience but Codex PHP was not (and still isn't) ready for use in Core. T399522 is the task we're waiting for.