The ForeignWikiRequest class in Echo depends uses a CentralAuth-specific way to make authenticated HTTP requests to another wiki. This doesn't work for wikis that use a shared user table setup.

ForeignWikiRequest first does an internal request for api.php?action=centralauthtoken, which returns a single-use token that CentralAuth stores in its session store. It then makes an HTTP request to the foreign wiki, passing in ?centralauthtoken=123abc in the query string. The foreign wiki then checks that 123abc matches the value in the session store, and automatically authenticates as the correct user.

Although a lot of CentralAuth's functionality was generalized in the SessionManager interface and its friends in MediaWiki core, this single-use authentication token functionality wasn't. It's CentralAuth-specific, and the code for generating the token is in an action API module, so it doesn't provide a real PHP-side interface for getting it.

We could generalize this interface, put it in MW core with an implementation that would work for a shared user table setup with a shared session store (or just within the same wiki), and have CentralAuth override it with its own code.

That would require 1) a way to identify users across wikis (probably we could just use CentralIdLookup), 2) the concept of a central token store (trivial, just needs a config variable), 3) a way to indicate which extension is managing the central token used for the request, and a way for that extension to veto the token (CentralAuth would do this for in-progress renames). That all seems quite easy to move to core.

CentralAuth also includes a central user token (ie. a shared version of the user_token field) in the data stored and validated when performing these requests. That's less trivial but TBH I'm not sure what useful security property it provides; maybe it can just be omitted.

Why does Echo need to do cross-wiki API requests? Can't it just look up the notifications from the relevant database tables directly skipping the API layer entirely?

In T337185#8961751, @taavi wrote:

Why does Echo need to do cross-wiki API requests? Can't it just look up the notifications from the relevant database tables directly skipping the API layer entirely?

The main reasons it can't do that are:

• Notification types are defined by extensions, and not all wikis have the same set of extensions installed. So wiki A may not know how to interpret all notification types from wiki B, because it doesn't have the right software installed.
• In order to render notifications correctly, you need to be able to map user IDs to user names, page IDs to page names, and namespace IDs to namespace names, among other things. Some of these things (users and pages) might theoretically be doable by looking at the other wiki's database, but others (namespaces) require access to the other wiki's config and/or may depend on the wiki's content language.
• The i18n messages used for the notification text can be overridden on a per-wiki basis
• ...and probably lots of other issues

Generally speaking, we don't have a good tool for wiki A running code "in the context of" wiki B, with all the right config and extensions, and all the points above are reasons why it would be difficult to build such a thing. Until we do, the only way to do this is to make an HTTP request to ourselves with a different domain name.