Page MenuHomePhabricator

Allow MediaWiki to make authenticated requests to other instances of MediaWiki
Open, MediumPublicFeature

Description

MediaWiki may make API requests to other instances of MediaWiki, sometimes operated by different entities in different networks. It should be possible to authenticate such requests, to avoid issues with rate limits, and potentially also to allow cross-wiki access to certain information to be restricted.

Implementation note: Owner-only OAuth tokens provide a simple but effective mechanism to achieve this. However, for WMF sites, this by itself is not sufficient to benefit from improved rate limits. The client also needs to support cookies that persist between request.

Original Report

As the co-administrator of a MediaWiki that interacts with Wikimedia wikis, I want MediaWiki to comply with Wikimedia’s user agent policy, in order to have my wiki continue to work as Wikimedia enforces this policy more and more stringently.

As the WMF and WMDE, given that we want third-party wikis to exist {{citation needed}}[1], [2], we want released MediaWiki versions to be able to interact with Wikimedia wikis.

Problem:
Several places in MediaWiki make API requests to other wikis, often Wikimedia wikis, including:

  • MediaWikiPageNameNormalizer, called by Site::normalizePageName(), e.g. when adding a sitelink to a Wikibase item
  • ForeignAPIRepo, used by (I think) InstantCommons

However, they don’t allow site administrators to improve the API requests. MediaWikiPageNameNormalizer has a very poor user agent (ForeignAPIRepo’s is better since T400881), neither makes the user agent customizable (e.g. via a configuration variable), and it’s not possible to authorize the request in any way.

Previous discussion:
https://www.mediawiki.org/wiki/Talk:Wikimedia_APIs/Rate_limits#Wikipedia_sitelink_lookups_being_rate_limited_on_FactGrid

Event Timeline

Change #1278551 had a related patch set uploaded (by Lucas Werkmeister; author: Lucas Werkmeister):

[mediawiki/core@master] Add User-Agent to MediaWikiPageNameNormalizer

https://gerrit.wikimedia.org/r/1278551

Change #1278552 had a related patch set uploaded (by Lucas Werkmeister; author: Lucas Werkmeister):

[mediawiki/core@master] Add $wgSiteAccessTokens configuration

https://gerrit.wikimedia.org/r/1278552

Change #1278553 had a related patch set uploaded (by Lucas Werkmeister; author: Lucas Werkmeister):

[mediawiki/core@master] Also use $wgSiteAccessTokens in ForeignAPIRepo

https://gerrit.wikimedia.org/r/1278553

The above three patches are currently deployed on FactGrid, though it’s unclear how much they help. (The first one alone had no effect other than changing the error message a bit, see discussion; I haven’t yet heard back from the wiki editors about the other two changes.) They’re probably not ready for merging as-is, but more of a starting point. (But it would be nice to get something merged and backported soon, given that the rate limit rollout continues unabated.)

(The task title and/or description could probably still do with some refining. Arguably the user agent part is covered by T422686; but beyond that, I think site operators need the ability to send authorized requests so they get higher rate limits, and that’s what the second and third patch attached above try to do.)

Does MWHttpRequest automatically support cookies, and if yes, where does it persist them? This is necessary to get better rate limits when using owner-only tokens. (https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits/FAQ#Why_do_I_need_to_send_cookies_with_owner-only_consumers_and_OAuth_1.0?)

daniel renamed this task from Make MediaWiki comply with Wikimedia user agent policy to Allow MediaWiki to make authenticated requests to other instances of MediaWiki.Apr 29 2026, 3:25 PM
daniel updated the task description. (Show Details)

Does MWHttpRequest automatically support cookies, and if yes, where does it persist them? This is necessary to get better rate limits when using owner-only tokens. (https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits/FAQ#Why_do_I_need_to_send_cookies_with_owner-only_consumers_and_OAuth_1.0?)

MWHttpRequest suppotrs a cookie jar, but it's in-memory only. At a glance, it's only used by the installer, in MailingListSubscribeTask.

The only concrete implementation of MWHttpRequest is GuzzleHttpRequest, and Guzzle also supports cookies, with its own cookie jar implementation. It would probably make sense to merge them. In any case, it should be easy to implement either cookie jar interface based on a BagOStuff, so the cookies can be persisted between requests in memcached to redis or cassandra or sql.

HCoplin-WMF lowered the priority of this task from High to Medium.Mon, Jul 6, 8:12 PM
HCoplin-WMF added subscribers: Tgr, HCoplin-WMF.

Hey there -- thanks for flagging this and creating some initial patches! Just wanted to chime in that we will take a deeper look at this soon. Also wanted to flag that @Tgr will be working on the client credential flow over the next few months, to make some improvements to ensure that it works as expected. It seems like a much better option than the owner-only/API token flows for this use case.

My suggestion would be that we wait for the client credential work to be completed, then revisit this from that lens. If we go with that approach, my understanding is that we would also not need to add the cookie support (but could still optionally include for additional flexibility).

We can look into pulling this in as a stretch goal to the PP3.5.4 hypothesis we are starting now, or treat it as a follow up after that work is complete. @Tgr can weigh in on his preference, and the additional scope this might add.